RFR: JDK-8210829: Modularize allocations in C2

Roman Kennke rkennke at redhat.com
Wed Sep 19 17:08:11 UTC 2018


Alright, submit repo came back with UNSTABLE. Can somebody here check it
and get back to me?

Build Details: 2018-09-19-1536076.roman.source
0 Failed Tests
Mach5 Tasks Results Summary

    KILLED: 0
    PASSED: 70
    UNABLE_TO_RUN: 3
    NA: 0
    FAILED: 0
    EXECUTED_WITH_FAILURE: 2
    Test

        2 Not run

tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-57
Dependency task failed:
mach5...-1909-solaris-sparcv9-solaris-sparcv9-build-8

tier1-solaris-sparc-jdk_open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-debug-58
Dependency task failed:
mach5...solaris-sparcv9-debug-solaris-sparcv9-build-9


> 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
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20180919/f0e5191c/signature.asc>


More information about the hotspot-gc-dev mailing list