Community
Participate
Working Groups
3.8 RC3: Follow up from https://bugs.eclipse.org/bugs/show_bug.cgi?id=381605. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=380313#c13. The RC3 compiler foregoes some opportunities to share finally blocks as subroutine in some instances by resorting to a very orthodox, "politically correct" code generation. In org.eclipse.pde.internal.ui.refactoring.PluginManifestChange.createRenameChange, we don't share the finally body as a subroutine between two return points: (1) if (!model.isLoaded()) return null; // FlowInfo<def: 3903, pot: 3903> and (2) the return null; // FlowInfo<def: 1855, pot: 1855> statement post the catch block. At point (1) the local `model' is defined and initialized while at point (2) the local `model' is undefined and uninitialized. Unlike the example in bug# 380313 comment# 13, here in this case in all paths that precede the second return statement (indeed there is only one path), define the local `model' so the stack shape will not be inconsistent at the second return and so the reset of locals implemented via bug 380313 needlessly forces the state indices to be different.
See that subroutine sharing for return statements in very primitive anyways. (1) A return of the form: return 10; and return 20; cannot share the subroutine. (2) A return of the form return 10; and return x; // where x is not a compile time constant cannot share the subroutine. (3) A return of the form return x; // not a compile time constant and return y; // not a compile time constant. cannot share the subroutine. At least at a first glance it us unclear why these limitations should exist. If we introduce a secret variable to capture the return value that conforms to the method's return type and use it to store the actual return value, it should be possible to share suboutines much more.
What is the implication of this bug? Are we reporting an "uninitialized variable" where the variable is initialized? If not, is the only implication of not sharing the subroutine is more code being unnecessarily generated?
(In reply to comment #2) > What is the implication of this bug? Are we reporting an "uninitialized > variable" where the variable is initialized? No, there is no correctness issue here. > If not, is the only implication of not sharing the subroutine is more code > being unnecessarily generated? Yes, and only in specific situations we forego the sharing which is originally implemented in limited situations to begin with as documented in comment#1
(In reply to comment #3) > (In reply to comment #2) > > What is the implication of this bug? Are we reporting an "uninitialized > > variable" where the variable is initialized? > > No, there is no correctness issue here. If anything it is "too correct", the space optimization I am suggesting requires us to "fudge the facts" albeit in a harmless way.
Also please note that for the code below which is structurally similar to the PluginManifestChange.java's relevant method, the finally block code emission count matches between oracle JDK7 and eclipse 3.8 RC3: // ------------------- public class X { public Object foo(X x1, X x2) { try { try { X x3 = null; if (x1 != null) { foo(x3, null); return null; } } catch (Exception e) { return null; } return null; } finally { System.out.println("Finally"); } } } // --------------------------
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
