jfdk Files

UPDATE : After talking to some redhat devs and doing more tests, it seems these patches are unnecessary.
I must have performed some tests with an older JVM.  Newer JVMs (JDK12+) seem fine when using object pinning.

jfdk (JavaForce Development Kit)
================================

jfdk is a fork of the OpenJDK with a minor modification so that the Shenandoah GC skips the compacting phases.
This GC supports pinning (JNI functions GetPrimitiveArrayCritical / ReleasePrimitiveArrayCritical) but normally that prevents the GC from functioning.
But by skipping the compacting phases pinning works without blocking the GC. This enables greater native performance and possibly faster GC operation.
Already finding 4x performance gains in apps built with JFDK.

Instructions:

Download latest JDK sources:

http://hg.openjdk.java.net/jdk/jdk/

Run patch.java

  java patch.java

Then do "bash configure" and "bash make images" to build.

What the patches do:

Edit Shenandoah sources:

src\hotspot\share\gc\shenandoah\shenandoahMarkCompact.cpp

comment all lines from:
  heap->set_full_gc_move_in_progress(true);
to:
  heap->set_full_gc_move_in_progress(false);
inclusive.

To remove the need for -XX:+UnlockExperimentalVMOptions you could edit the GC config file:

src\hotspot\share\gc\shared\gc_globals.hpp

and change:
  experimental(bool, UseShenandoahGC
to:
  product(bool, UseShenandoahGC

Since keeping track of pinning is not required, edit:

src\hotspot\share\gc\shenandoah\shenandoahHeap.cpp

And comment the following lines:
  heap_region_containing(o)->record_pin();
  heap_region_containing(o)->record_unpin();

To make Shenandoah the default GC edit:

src/hotspot/share/gc/shared/gcConfig.cpp:

in function select_gc_ergonomically make sure UseShenandoahGC is first.

I've tested some large GB apps and it seems to work fine.
Now it's possible to pass LARGE arrays to JNI functions using (GetPrimitiveArrayCritical / ReleasePrimitiveArrayCritical)
without the JVM "copying" them thereby crippling performance.

Why is Java so bent on compacting memory?  C++ lives with fragmented memory.
Maybe 32bit JVMs required it but in this 64bit era I don't think it's required anymore.
It fact, skipping the compacting phases probably improves performance.

Thanks,

Version 0.2
Released Dec 20, 2019

Peter Quiring (pquiring at gmail dot com)

Version History:

0.2 : Dec 19, 2019
 - created patch.java to automate the process
 - removed record_pin() and record_unpin()
 - changed experimental to product
 - made Shenandoah default GC (no command line options needed anymore)

0.1 : Dec 17, 2019
 - init releasse
 - manually patched sources