You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by ac...@apache.org on 2005/10/02 05:45:02 UTC
RT: Escape analysis
http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html - Yummy.
Re: RT: Escape analysis
Posted by John Whaley <jo...@gmail.com>.
On 10/3/05, Robin Garner <Ro...@anu.edu.au> wrote:
> Florian Weimer wrote:
>
> The conclusion reached in the OOPSLA paper referred to (Choi et al 1999)
> is that stack allocation produced a relatively insignificant speedup,
> but that locking optimizations for objects that don't escape thread
> context was significant.
>
> In a heap with a bump-pointer allocator, allocation is cheap. Stack
> allocation can potentially produce a slow-down by reducing locality in
> the stack, and complicating the task of scanning the stack.
>
Another problem with stack allocation is that it increases object
lifetimes because you cannot reclaim the storage until the stack frame
disappears. It is possible to work around this if your escape
analysis is sophisticated enough.
Synchronization overhead definitely improves, but synchronization was
so slow for such a long time that many mature programs already
eliminate the synchronization by hand (consider ArrayList vs. Vector).
Doing escape analysis in a JIT is not difficult; see, for example, my
OOPSLA'01 paper or Suganuma et al PLDI'03.
The real performance benefit of escape analysis is when you can do
scalar replacement, replacing each of the object's fields/array
elements with a register. Thus, you eliminate the object entirely,
and making its fields into registers allows many more optimizations.
John Whaley
Re: RT: Escape analysis
Posted by Robin Garner <Ro...@anu.edu.au>.
Florian Weimer wrote:
>>http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html - Yummy.
>>
>>
>
>Soot and JCVM already implement this as well, IIRC. The problems Tim
>mentioned are addressed by JCVM by relying on inlining to expose stack
>allocation opportunities.
>
>
The conclusion reached in the OOPSLA paper referred to (Choi et al 1999)
is that stack allocation produced a relatively insignificant speedup,
but that locking optimizations for objects that don't escape thread
context was significant.
In a heap with a bump-pointer allocator, allocation is cheap. Stack
allocation can potentially produce a slow-down by reducing locality in
the stack, and complicating the task of scanning the stack.
-- Robin
Re: RT: Escape analysis
Posted by Florian Weimer <fw...@deneb.enyo.de>.
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html - Yummy.
Soot and JCVM already implement this as well, IIRC. The problems Tim
mentioned are addressed by JCVM by relying on inlining to expose stack
allocation opportunities.
Re: RT: Escape analysis
Posted by Tim Ellison <t....@gmail.com>.
What Brian fails to mention though is the speculative nature of such
optimizations in the presence of polymorphism.
Since Point and Component are not declared final/private they could at
some point be subclassed to, say, not simply return x from getx() or
return a new Point from getLocation(). Obviously if that happens the
pseudocode in listing 4 would do 'the wrong thing'.
The VM/JIT either has to be conservative, or able to undo such
speculative optimizations if the assumptions later prove false. The
ability to undo optimizations requires some book-keeping.
Regards,
Tim
acoliver@apache.org wrote:
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html - Yummy.
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: RT: Escape analysis
Posted by Tom Tromey <tr...@redhat.com>.
>>>>> "Andy" == acoliver <ac...@apache.org> writes:
Andy> A principle reason for {} scoping is that it allows register
Andy> allocation ; however, it is practically useless in the above. 9/10
Andy> you're going to have to put "myvar" in at least method scope so that
Andy> you can get at it outside of the t/c. That defeats register
Andy> allocation in many cases anyhow.
I don't think this matters to a JIT, sine the braces and declarations
don't appear in any meaningful way in the bytecode. And, as it is
common for java compilers to reuse local variable slots in a method
body (often with different types), presumably JITs have to do real
liveness analysis anyway.
Andy> I'd also like to be able to opt out of checked exceptions such that
Andy> they are autowrapped at runtime exceptions. I agree with Microsoft on
Andy> that one. It took me awhile...but checked exceptions do more harm
Andy> than good.
This is a java->bytecode compiler issue, not a runtime issue.
Checked exceptions are only checked by the compiler, not by the VM.
Tom
Re: RT: Escape analysis
Posted by ac...@apache.org.
Yeah I thunk it some time ago too. I think I even commented on that
one. I'd also like "descoping"
try -{
String myvar = "Hey";
}- catch {
System.out.println(myvar);
}
System.out.println(myvar);
A principle reason for {} scoping is that it allows register allocation
; however, it is practically useless in the above. 9/10 you're going to
have to put "myvar" in at least method scope so that you can get at it
outside of the t/c. That defeats register allocation in many cases
anyhow. The above example is doofy but there are many cases when you're
getting a result back inside a t/c and want to save it...that makes you
predeclare it.
I'd also like to be able to opt out of checked exceptions such that they
are autowrapped at runtime exceptions. I agree with Microsoft on that
one. It took me awhile...but checked exceptions do more harm than good.
If anyone's interested I'll look up my more comprehensive list that I
had of VM/Java "wishes" for JDK 6.
-andy
Geir Magnusson Jr. wrote:
> My friend Cameron has been thinking about this too. (I call Brian a
> friend as well...)
>
> http://www.jroller.com/page/cpurdy?entry=threading_and_escape_analysis
>
> On Oct 1, 2005, at 11:45 PM, acoliver@apache.org wrote:
>
>> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html -
>> Yummy.
>>
>>
Re: RT: Escape analysis
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
My friend Cameron has been thinking about this too. (I call Brian a
friend as well...)
http://www.jroller.com/page/cpurdy?entry=threading_and_escape_analysis
On Oct 1, 2005, at 11:45 PM, acoliver@apache.org wrote:
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
> - Yummy.
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org