RFR: Fixing Windows and ARM32 build

[Roman Kennke]

Am 08.05.2018 um 00:07 schrieb Zhengyu Gu:
> 
> 
> On 05/07/2018 04:34 PM, Roman Kennke wrote:
>> Am 07.05.2018 um 22:22 schrieb Zhengyu Gu:
>>> Apparently, you cannot avoids precompiled headers for selected files on
>>> Windows, or you have to turn it off all together.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/shenandoah/win-build/webrev.00/
>>>
>>> Test:
>>>
>>>    Windows X64 PCH and Non-PCH builds
>>>    Linux x64 PCH and Non-PCH builds
>>>    ARM32 PCH and Non-PCH builds
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>
>> IIRC, Aleksey did not want this:
>> -  Atomic::add(-bytes, &_used);
>> +  Atomic::sub(bytes, &_used);
>>
>> because backports.
> 
> VSC++ does not like it:
> 
> /shenandoah-jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp(595)
> : warning C4146: unary minus operator applied to unsigned type, result
> still unsigned
> 
> so, we have to suppress warning at call site to avoid warnings-as-errors
> build failure, sounds like not making backports any easier.

Ok. It's good for me, probably let Aleksey confirm, he should at least
have it on his radar ;-)


>> Why is this needed:
>> -  write_ref_array_pre_work(T* dst, int count);
>> +  write_ref_array_pre_work(T* dst, size_t count);
>>
> VSC++ wants explicit casting. G1BassierSet uses size_t here, probably we
> should do so to avoid casting, also for consistency.
> 
> Do you see any issues here?

No, it's ok, I just wanted to understand.

>> ?
>>
>> Is the change in src/hotspot/os/windows/attachListener_windows.cpp
>> needed? If yes, then upstream it?
> 
> Ah, someone beats me on this.  Looks like upstream fixed in JDK-8200729.
> I will revert this one.

You can also ship the fix. If it's identical to what upstream pushed, it
will be smooth merging.

Roman