Support Shenandoah GC / jdk 25

[ivan-velikanov]

Description

JDK25 comes with Shenandoah GC feature stabalized.
However using these options :
-J-XX:+UseShenandoahGC -J-XX:ShenandoahGCMode=generational in the netbeans.conf file results in netbeans not even starting. Is it possible to support this GC ?

Use case/motivation

I have read that ShenandoahGC is more liberal in returning memory/RAM to the system. Overtime the VM consumes more RAM/heap-size even though actual usage might fluctuate and might be usually low. However this appears as a high ram usage and appears to affect the overall system performance. Currently the only way out is to restart netbeans as simple GC just frees objects from heap but doesn't reduce heap size.

Related issues

No response

Are you willing to submit a pull request?

No

[matthiasblaesing]

You'll need a JDK with Shenandoa enabled. You can configure that on CLI using --jdkhome. Actually GC1 does return memory: https://openjdk.org/jeps/346 to the OS.

[mbien]

However using these options : -J-XX:+UseShenandoahGC -J-XX:ShenandoahGCMode=generational in the netbeans.conf file results in netbeans not even starting. Is it possible to support this GC ?

Oracle doesn't ship the Shenandoah GC so it could be that it isn't in the JDK you are running NB on. (all other distributions should have it since it is the default build option I believe)

So if the GC isn't found check what JDK you are running NB on. The JDK+NB 27 packages bundle zulu 24 for example which does have all GCs too.

(And yes as Matthias mentioned above, G1 can return memory to the system too)

[mbien]

also: generational mode is early access, you will have to set -J-XX:+UnlockExperimentalVMOptions too

[ivan-velikanov]

In jdk25 they have marked it as a release version. I did not know they don't ship it with oracle. I will try the settings mentioned. Thank you @mbien and @matthiasblaesing

Though G1 can return memory, i think it happens only when it is idle, and I did not observe that happening when I needed some memory freed (as my browser was hogging it from another side). I am hoping if Shenandoah can make some improvements in this and be more agressive in returning ram .. let's see.

[ivan-velikanov]

Shenondoah seems to work with zulu jdk25 (not with oracle 25) ... GC felt faster, agressive, lower cpu usage, appears to return memory to system more liberally than G1 (with the following settings):

 -J-XX:+UnlockExperimentalVMOptions -J-XX:+UseShenandoahGC -J-XX:ShenandoahGCMode=generational -J-XX:ShenandoahGuaranteedGCInterval=10000 -J-Xms200m -J-Xmx600m -J-XX:ShenandoahUncommitDelay=60000 -J-XX:ShenandoahGuaranteedGCInterval=120000 

In idle time i saw heap usage go below 200MB and Heap size at around 200MB ...

(I think this is not required -J-XX:+UnlockExperimentalVMOptions in jdk25 ... but still i kept it to be on safer side. )

[lkishalmi]

Well actually with recent JDK-s if you are a bit low on memory G1 is the best choice. Shenondoah and ZGC has more focus on low latency GC, which is not really that appealing for an IDE use-case. That also comes more native memory overhead (8-10% of Heap space vs ~2% on G1)

Also yes G1 is also capable of give back memory to the OS if there is a memory pressure (or manually enforced full GC).

If you are bit low on RAM the best thing would be limit the maximum heap and use -XX:+UseCompactObjectHeaders .
With that and G1 the IDE works surprisingly well with sub 1Gb max heap space.

[mbien]

Shenondoah is also quite good for small heaps, since the footprint and its memory management overhead is small. (but G1 got better at reducing overhead too in recent releases).

For small heap/embedded I usually pick between serial, parallel or shenandoah, dependent on the requirements (e.g does latency matter, core count, etc). Shenandoah was in fact the first low latency GC i tested for embedded aarch64 after CMS was discontinued since it got ported to arm fairly early on.

But for IDEs like NB on desktops, G1 is still a pretty good default. It is still being improved and it has a good balance between latency, overhead and throughput (essentially a mix between parallel and old CMS without the risk of heap fragmentation which CMS had).

(I run NB 28 with -J-Xms2G -J-Xmx6G -J-XX:+UseCompactObjectHeaders)