On Wed, Oct 17, 2012 at 2:07 PM, Christian Thalinger <christian.thalin...@oracle.com> wrote: > On Oct 17, 2012, at 8:33 AM, David Chase <david.r.ch...@oracle.com> wrote: >> >> I'm very new to this (have not even looked at the source code to Hotspot >> yet), but is it possible >> to push the allocation/boxing to paths that are believed to be rarely taken? > > That's what partial EA does. I'm trying to get Vladimir to work on it and it > seems I'm successful.
I started reading a bit about partial EA last night, specifically looking at how PyPy does it. In PyPy, the JIT treats accesses and calls against an object as acting against a virtual object. I did not see if they actually allocate stack space for this, but my guess is that it's "virtual" in that the data moves are still unoptimized, unemitted operations in the IR representation. If at some point the code calls a branch that would need to see the actual object, they reconstitute it based on the actual values at that point. The concerns some have brought up about construction seem like non-issues here; if the constructor chain is simple and just does field updates (and doesn't allow the object to escape) then the inlined version of the constructor can be treated as acting against the virtual object (again, perhaps against stack-allocated object, or just represented as object accesses in IR), so it still "runs" when it's supposed to. The object reconstitution that happens later just copies the current virtual object contents into new memory, and proceeds from there. I know very little about the current EA implementation in Hotspot. Was it designed to be able to eventually support partial EA? - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
