RFR: Remove obsolete and unused reduce-storeval-barrier optimization code
Roman Kennke
roman at kennke.org
Mon Sep 18 13:52:23 UTC 2017
Am 18.09.2017 um 15:41 schrieb Aleksey Shipilev:
> On 09/18/2017 03:30 PM, Roman Kennke wrote:
>> Am 18.09.2017 um 11:58 schrieb Aleksey Shipilev:
>>> On 09/16/2017 11:37 AM, Roman Kennke wrote:
>>>> Ok. I fixed one place in library_call.cpp in the cmpxchg intrinsics. Everything else should be ok:
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.01/
>>> *) I wonder if instead of putting shenandoah_storeval_barrier prior to store_oop_* calls, we are
>>> better putting the barriers calls inside of them? Under UseShenandoahGC flag? Otherwise, I see
>>> missing shenandoah_storeval_barrier in GraphKit::builtin_throw and Parse::expand_multianewarray.
>>>
>>> Seems good otherwise.
>> Good point. Like this?
>>
>> http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.02/
> Looks better.
>
> So, the shenandoah_storeval_barrier from LibraryCallKit::LibraryCallKit::inline_unsafe_load_store is
> now subsumed by something else? Can't see by what.
Good catch!
I re-instated the storeval-barrier in the T_OBJECT versions of the
unsafe_load_store intrinsics, the same way it has been before I
introduced the optimization back then:
http://cr.openjdk.java.net/~rkennke/remove-reduce-storeval/webrev.03/
<http://cr.openjdk.java.net/%7Erkennke/remove-reduce-storeval/webrev.03/>
Roman
More information about the shenandoah-dev
mailing list