4 ms·

One neat feature of Shenandoah is once the application shuts down, it prints into the GC log a table depicting how much time each phase of the GC cycle took. Th

by enduku 5y ago

One neat feature of Shenandoah is once the application shuts down, it prints into the GC log a table depicting how much time each phase of the GC cycle took. This data can be crucial to optimize the GC pause time further: - Removal of weak references (finalizer, phantom, soft) can help reduce the GC pause time further as these warrant stop the world phase - Shenandoah likes ReentrantLocks better than synchronised classes the latter bloats up its monitors and increases the size of the rootset - The reflection problem may initial Shenandoah to run GC cycles even when there is no memory pressure and thus may reduce performance over time. It is better to limit it using reflection inflation flag - On Amazon ECS, provide the CPU share count explicitly; Shenandoah likes more threads

tpxl 5y ago
> One neat feature of Shenandoah is once the application shuts down, it prints into the GC log a table depicting how much time each phase of the GC cycle took. This data can be crucial to optimize the GC pause time further Other GCs will do the same for you (G1, ZGC) which you can then put into a tool like gceasy to pretty graphs.
raducu 5y ago
> - Removal of weak references (finalizer, phantom, soft) can help reduce the GC pause time further as these warrant stop the world phase I'm in way disputing this, but why would a weak reference be different than any other reference, beyond the added flexibility it gives the GC (you may or may not GC this reference if you please)? I admit I don't give GC much thought beyond every coupe of years when I switch jobs :)
- eropple 5y ago
  I haven't looked at Shenandoah and my GC experience is a bit stale, but to determine if something is weakly referenced, you need to determine whether or not something is universally weakly referenced. A strong reference anywhere means it isn't weakly referenced at all, and as I recall it's been thought (for now) that while this may not require stopping the world to sweep the full set of references, it's a safer and more correct option.
- kllrnohj 5y ago
  Consider if during collection an object that was only reachable becomes strongly reachable as a result of promotion. This needs to be reconciled at some point, and there's also atomicity expectations. If there's 2 weak references for the same object, you can't have one return non-null after the other already returned null (part of the API requirements: https://docs.oracle.com/javase/8/docs/api/java/lang/ref/WeakReference.html https://docs.oracle.com/javase/8/docs/api/java/lang/ref/Weak... ) The easiest way to handle this conflict is to just pause the world when doing the processing of weakrefs after the concurrent GC finishes.
mwcampbell 5y ago
> - On Amazon ECS, provide the CPU share count explicitly; Shenandoah likes more threads Can you explain this further? I'm missing some connection here between ECS configuration and how the JVM sees the container.
- WJW 5y ago
  Not OP, but many systems will scale the amount of threads based on the core count in your system. So on a 32-core system you might have 32 GC threads. On ECS (and many other container orchestrators) when you set some CPU allocation like perhaps 0.2 CPU, your process will still "see" all the CPUs present in the system but the process will just not be scheduled if the allocation for this time period has been used up. This could cause Shenandoah to over-allocate GC threads and eat into your CPU allocation.
- enduku 5y ago
  Based on the number of CPU cores on the machine, Shenandoah sets up its threads. JVM will see only one CPU core if the number of CPU shares for the container is not set explicitly[0]. In that case, Shenandoah will use only single parallel thread to do the collections, and the entire application may crash. [0]https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
  - mwcampbell 5y ago
    Ah, right. I wish ECS had an option to expose all of an EC2 instance's underlying cores to a container with no constraints. In that case, the scheduler could use the memoryReservation setting to figure out which containers can fit on which instances.
rkennke 5y ago
Notice that with Shenandoah GC, weak references are handled concurrently since JDK 16, native roots like locks, classes, etc are handled concurrently since JDK 14. Therfore the first 3 problems that you mentioned are solved. Follow the links the OP article to find explanations for each of these improvements. BTW, you can specify the number of GC threads that you like to use -XX:ConcGCThreads=X -XX:ParallelGCThreads=Y (X for concurrent GC, Y for STW pauses - which should no longer be very relevant). Cheers!

by enduku 5y ago

tpxl 5y ago

> One neat feature of Shenandoah is once the application shuts down, it prints into the GC log a table depicting how much time each phase of the GC cycle took. This data can be crucial to optimize the GC pause time further Other GCs will do the same for you (G1, ZGC) which you can then put into a tool like gceasy to pretty graphs.

raducu 5y ago

> - Removal of weak references (finalizer, phantom, soft) can help reduce the GC pause time further as these warrant stop the world phase I'm in way disputing this, but why would a weak reference be different than any other reference, beyond the added flexibility it gives the GC (you may or may not GC this reference if you please)? I admit I don't give GC much thought beyond every coupe of years when I switch jobs :)

eropple 5y ago
I haven't looked at Shenandoah and my GC experience is a bit stale, but to determine if something is weakly referenced, you need to determine whether or not something is universally weakly referenced. A strong reference anywhere means it isn't weakly referenced at all, and as I recall it's been thought (for now) that while this may not require stopping the world to sweep the full set of references, it's a safer and more correct option.
kllrnohj 5y ago
Consider if during collection an object that was only reachable becomes strongly reachable as a result of promotion. This needs to be reconciled at some point, and there's also atomicity expectations. If there's 2 weak references for the same object, you can't have one return non-null after the other already returned null (part of the API requirements: https://docs.oracle.com/javase/8/docs/api/java/lang/ref/WeakReference.html https://docs.oracle.com/javase/8/docs/api/java/lang/ref/Weak... ) The easiest way to handle this conflict is to just pause the world when doing the processing of weakrefs after the concurrent GC finishes.

mwcampbell 5y ago

> - On Amazon ECS, provide the CPU share count explicitly; Shenandoah likes more threads Can you explain this further? I'm missing some connection here between ECS configuration and how the JVM sees the container.

WJW 5y ago
Not OP, but many systems will scale the amount of threads based on the core count in your system. So on a 32-core system you might have 32 GC threads. On ECS (and many other container orchestrators) when you set some CPU allocation like perhaps 0.2 CPU, your process will still "see" all the CPUs present in the system but the process will just not be scheduled if the allocation for this time period has been used up. This could cause Shenandoah to over-allocate GC threads and eat into your CPU allocation.
enduku 5y ago
Based on the number of CPU cores on the machine, Shenandoah sets up its threads. JVM will see only one CPU core if the number of CPU shares for the container is not set explicitly[0]. In that case, Shenandoah will use only single parallel thread to do the collections, and the entire application may crash. [0]https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_environment https://docs.aws.amazon.com/AmazonECS/latest/developerguide/...
- mwcampbell 5y ago
  Ah, right. I wish ECS had an option to expose all of an EC2 instance's underlying cores to a container with no constraints. In that case, the scheduler could use the memoryReservation setting to figure out which containers can fit on which instances.

rkennke 5y ago

Notice that with Shenandoah GC, weak references are handled concurrently since JDK 16, native roots like locks, classes, etc are handled concurrently since JDK 14. Therfore the first 3 problems that you mentioned are solved. Follow the links the OP article to find explanations for each of these improvements. BTW, you can specify the number of GC threads that you like to use -XX:ConcGCThreads=X -XX:ParallelGCThreads=Y (X for concurrent GC, Y for STW pauses - which should no longer be very relevant). Cheers!