RFR [8]: Fix x86_32 build
Roman Kennke
rkennke at redhat.com
Wed Jul 18 10:20:05 UTC 2018
Am 18.07.2018 um 12:18 schrieb Aleksey Shipilev:
> On 07/18/2018 12:08 PM, Roman Kennke wrote:
>> Am 18.07.2018 um 11:43 schrieb Aleksey Shipilev:
>>> sh/jdk8u build on x86_32 fails because there is no Atomic::load for intptr_t in jdk8:
>>>
>>> diff -r 3b776ba499bb src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp
>>> --- a/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Mon Jul 16 11:57:03 2018 -0400
>>> +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Wed Jul 18 11:43:11 2018 +0200
>>> @@ -210,11 +210,11 @@
>>> intptr_t tax = MAX2<intptr_t>(1, (intptr_t)(words * OrderAccess::load_acquire(&_tax_rate)));
>>> Atomic::add(tax, &_budget);
>>> }
>>>
>>> intptr_t ShenandoahPacer::epoch() {
>>> - return Atomic::load(&_epoch);
>>> + return OrderAccess::load_acquire(&_epoch);
>>> }
>>>
>>> void ShenandoahPacer::pace_for_alloc(size_t words) {
>>> assert(ShenandoahPacing, "Only be here when pacing is enabled");
>>>
>>>
>>> Testing: x86_32 build, tier1_gc_shenandoah
>>
>> Ok. Ordinary load doesn't do it? intptr_t on x86_32 is 32bit and atomic,
>> or is it not?
>
> It is shared between threads, so it is better to be somewhat recent. Other Pacer variables like that
> are using release/acquire already.
Ok
More information about the shenandoah-dev
mailing list