RFR: JDK-8210829: Modularize allocations in C2

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Sep 18 17:41:51 UTC 2018


Hi Roman,

This looks good. I looked through changes and it generates the same ideal graph as before.
It seems you unintentionally changed indent of the comment in barrierSetC2.hpp

Thanks,
Vladimir

On 9/18/18 12:58 AM, Roman Kennke wrote:
> Similar to what we've done before to runtime, interpreter and C1,
> allocations should be owned and implemented by GC, and possible to
> override by specific collectors. For example, Shenandoah lays out
> objects differently in heap, and needs one extra store to initialize
> objects.
> 
> This proposed change factors out the interesting part of object
> allocation (i.e. the actual allocation) into BarrierSetC2. It's mostly a
> move-and-rename-job. I had to move some little things around, that is:
> - for the need-gc-check, I'm passing back the needgc_ctrl to plug into
> slow-path
> - for prefetching, instead of passing around the 'length' node, only to
> determine the number of prefetch lines, I determine this early, and pass
> through the lines arg.
> - i_o, needgc_ctrl, fast_oop_ctrl, fast_oop_rawmem are passed as in/out
> or out-args to stitch together into the regions and phis as appropriate.
> I see no easy way around that.
> 
> I tested this using hotspot/jtreg:tier1 and also verified that this
> fills Shenandoah's needs and run tier3_gc_shenandoah testsuite.
> 
> http://cr.openjdk.java.net/~rkennke/JDK-8210829/webrev.00/
> 
> Can I please get reviews?
> Thanks,
> Roman
> 


More information about the hotspot-gc-dev mailing list