RFR: JDK-8210829: Modularize allocations in C2
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Sep 19 17:58:53 UTC 2018
Crypto library build failed - 8210912.
Mikael just pushed the fix - update your copy:
http://hg.openjdk.java.net/jdk/jdk/rev/15094d12a632
Vladimir
On 9/19/18 10:08 AM, Roman Kennke wrote:
> 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
>>>
>
>
More information about the hotspot-compiler-dev
mailing list