JDK 15 Reaches General Availability on 15 September 2020: EdDSA Embraced, Nashorn Expelled

 JDK 15 is unleashed! 

One of its fine features is support for EdDSA (Edwards Curve Digital Signature Algorithm described in RFC8032), an elliptic curve signature scheme. The Edwards Curve is named after the late American mathematician Harold Edwards who graduated with a PhD in mathematics in 1961 from Harvard.

One of JDK 15's high-profile "subtractions"is the Nashorn JavaScript engine (which has been removed as per recommendation of JEP372). Nashorn has been declared "challenging to maintain" with the rapid development of the ECMAScript standard underlying JavaScript.

The Z Garbage Collector gets a boost from being a mere "experimental feature" to now becoming a "product feature" as per JEP377 (without altering the default GC which remains G1). Nod to 377 author Per Liden.

What is the size of Eden?

What should the size of Eden be? Is 128mb sufficient?
What is the difference between a minor and major collection?

In Java memory is managed in generations, which are memory pools for holding objects of different ages.

GC occurs in each generation when it fills up.

Objects are ALLOCATED in Eden, and most objects die there. When Eden fills up, a minor collection occurs, during which some objects move to an older generation. When older objects need to be collected, a major collection occurs (this is often slower since it involves all living objects).

java.lang.OutOfMemoryError

Applications may sometimes terminate with java.lang.OutOfMemoryError. The error is thrown when there is insufficient space to allocate an object.

Why do I get this exception?

First, you must inspect the FULL error message: what comes after the java.lang.OutOfMemory error?

* example 1: Java heap space. Two possibilities here. Perhaps the specified heap size is insufficient for the application...in which case bump up the heap size using the -Xmx option. The alternative possibility is a problem in garbage collection e.g. objects that are no longer needed cannot be garbage collected because the application is unintentionally holding references to them. A common source of this error can be excessive use of finalizers such that the thread to invoke the finalizers cannot keep up with the rate of addition of finalizers to the queue. jconsole can monitor the number of objects pending finalization.

* example 2: Java PermGen space. "PermGen space" indicates the permanent generation is full. This is the area of the heap where the JVM stores its metadata. If an application loads a large number of classes the permanent generation may need to be increased (i.e. -XX:MaxPermSize=n, where n is the size).

* example 3: Requested array size exceeds VM limit. e.g. if max heap size is 256MB (2^8), an you try to allocate an array of 512MB (2^9 i.e. double the size) then you get the "array size exceeds VM limit" problem.

To diagnose OutOfMemoryErrors best tools to use are Heap Analysis Tool (HAT), jconsole management tool and the jmap tool with -histo option.

Is Java GC really better than C# GC? NO WAY! Java just hints, C# actually DOES stuff!

JAVA way: System.gc() -> Runtime.getRuntime().gc() - this is just a "hint" to JVM to do some cleanup
C# way: GC.Collect() -> this is a "command" to CLR, "clean up your act!" This will run all eligible object finalizers on a separate thread. Another important method is GC.WaitForPendingFinalizers, usually you call this after a GC.Collect. It makes a difference to the memory used by your program! You can also run a GC.Collect on a specific generation (generation 0 being the most recently allocated objects).

How EXACTLY does garbage collection work in Java?

gc -

main purpose: freeing memory from objects no longer referenced by the program

what does no longer referenced mean?

refcount==0

when is refcount==0? Most profilers use JVMPI or JVMTI (only in J2SE 5.0) to obtain reference counts of objects. MPI == machine profiler interface, MTI == machine tool interface (referring to the Java virtual machine of course).

secondary purpose: combat heap fragmentation (blocks of heap memory in-between blocks of live objects)

designer of each JVM must decide how to implement the gc-collected heap.

benefits:
1. productivity
2. security - prevent programmers from accidentally (or purposely) crashing the JVM by incorrectly freeing memory