[aarch64-port-dev ] [URGENT] RFR (XS): Adjust code stub sizes for Shenandoah and future backports

[Andrew John Hughes]

On 18/06/2019 21:43, Aleksey Shipilev wrote:
> On 6/18/19 10:41 PM, Andrew John Hughes wrote:
>> On 18/06/2019 20:27, Aleksey Shipilev wrote:
>>> http://cr.openjdk.java.net/~shade/shenandoah/8u-codestub-sizes/webrev.01/
>>>
>>> This is the unnumbered fix, because it is specific to Shenandoah 8u. I prefer to fix it right in
>>> integration forest to unblock testing. Current testing shows that Windows x86_64 fastdebug build
>>> cannot start with -XX:+UseShenandoahGC, because code stubs are too small to fit Shenandoah code. It
>>> is enough to fit the same code on Linux, though.
>>>
>>> So, we need to adjust it. Upstream code made multiple adjustments over the years, and I would prefer
>>> not to second-guess that, and just pick up the values from current jdk/jdk:
>>>   http://hg.openjdk.java.net/jdk/jdk/file/17f24c0e2f01/src/hotspot/cpu/x86/stubRoutines_x86.hpp#l34
>>>
>>> http://hg.openjdk.java.net/jdk/jdk/file/17f24c0e2f01/src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp#l42
>>>
>>> Testing: Shenandoah tests on {x86_64} x {Linux, Windows} x {release, fastdebug, slowdebug}
>>
>> Can this not be made conditional on Shenandoah being enabled? I'm wary
>> of us diverging from upstream here.
> 
> No, it is a compile-time constant, we cannot conditionalize it on runtime flag.
> 

Ah, I guess this is a side-effect of not being able to disable
Shenandoah at configure time on 8u.

> Bumping it up seems rather safe: it wastes a handful of kilobytes in buffers, but it is also tedious
> to update every time. This is why I bumped it all the way up to current jdk/jdk limits.
> 

Yeah, I'm not so worried about it being safe, so much as it means all
our builds from this tree - with or without Shenandoah being used - will
have a greater memory usage than builds from the upstream tree.

I guess it's ok, but seems like we do need to look at being able to
configure Shenandoah out at compile-time on 8u, especially if we want to
push it to upstream 8u at some point.

> -Aleksey
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew