Dynamic G1 barrier elision for C2 in young

[Thomas Schatzl]

Hi Erik,

On Sun, 2015-06-14 at 00:53 +0000, Erik Österlund wrote:
> Hi Vitaly,
> 
> Thank you for liking the idea! What I had in mind was optimizing young
> objects because it’s easy to reason about consistency, but I suppose in
> such cases even old objects could be optimized. But that would require
> more care and I don’t know how common such applications are as Java is
> widely marketed as having cheap allocations.

I like the idea too. I will run it through a few benchmarks and see if
there is more than dacapo benchmarks giving better numbers.

> Anyway, the approach could be refined much more if plugged into an
> engine for points-to analysis. It gives a set of possible allocation
> points for object references, which could in our case be exploited
> when emitting reference store code. If objects are then given different
> Klass pointers (soft handles) for different allocation points at runtime,
> then the approach could find more opportunities for barrier elision. In
> cases where the same class is used in different parts of code, sometimes
> as temporary objects and sometimes as old objects, the difference would
> be identified and barriers would be elided for the code dealing with the
> always temporary variants of the class, but not for code dealing with
> the potentially old objects of the same class. Not sure how low hanging
> that fruit is though… but C2 does some of that stuff already for lock
> elision using escape analysis I think, although not intra-procedural
> (yet) if I get it right. Could have a look when I have time if anyone is
> interested in this kind of stuff.

Always :) I believe there is a *lot* of untapped potential in making the
compiler consider GC activity for compilation.

Thanks,
  Thomas