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