JDK Vergleich Java 8

Der Jira-Server für dieses Makro konnte nicht gefunden werden. Das könnte an der Konfiguration des Anwendungslinks liegen.

Überblick:

Stand am 11.03: JDK Vergleich_Java8.pptx

Testumgebung:

Windows 10 mit Java 8

JDK:

1. Oracle JDK (jdk1.8.0_181)
2. Red hat OpenJDK (1.8.0.242-3.b08)
3. AdoptOpenJDK (jdk8u242-b08)
4. Azul Zulu JDK (1.8.0_242)

JMH Benchmarks modes:

• Throughput: operations per unit of time [Runs by continuously calling Benchmark methods,

       * counting the total throughput over all worker threads. This mode is time-based, and it will
       * run until the iteration time expires]

• AverageTime: average time per operation [Runs by continuously calling Benchmark methods,

       * counting the average time to call over all worker threads. This is the inverse of Mode#Throughput,
       * but with different aggregation policy. This mode is time-based, and it will run until the iteration time
       * expires.]

• SampleTime: samples the time for each operation [Runs by continuously calling Benchmark methods,

       * and randomly samples the time needed for the call. This mode automatically adjusts the sampling
       * frequency, but may omit some pauses which missed the sampling measurement. This mode is time-based, and it will
       * run until the iteration time expires.]

• SingleShotTime: measures the time for a single operation [Runs by calling Benchmark once and measuring its time.

  * This mode is useful to estimate the "cold" performance when you don't want to hide the warmup invocations, or * if you want to see the progress from call to call, or you want to record every single sample. This mode is * work-based, and will run only for a single invocation of {@link Benchmark} * method.]
  
  

Memory:

• Heap memory:  is the storage for Java objects.
• Non-heap memory: is used by Java to store loaded classes and other meta-data.
• The allocated memory is an overall amount of memory allocated by the JVM, while used memory is the amount of memory which is actually in use.

Ergebnisse:

05_square-annot-and-page-rotation.pdf (8 pages)

 Musterantrag.pdf (6 pages)

testdoc_rendering_pixel.png (1 page)

stat1.afp(4 pages)

Ergebnisse ohne Marlin:

AdoptOpenJDK: Insgesamt am langsamsten. Das merkwürdige Memory Management: die JVM teilt sehr hocheffizient heap-memory und nicht rational non-heap memory zu, der nicht voll verwendet ist. Es könnte nützlich sein für eine hohe horizontale Skalierbarkeit aufgrund des geringen Heapspeichers.

Oracle JDK: Mittleres JDK mit Performance. Dies könnte jedoch aufgrund der Oracle Änderungen am Lizenzmodell zu Problemen bei der Lizenzierung für große Unternehmen führen.

RedHatOpenJDK: Manchmal am schnellsten, aber nicht konsequent. Keine Lizenzierung Probleme. Allerdings etwas hinter Zulu

Zulu OpenJDK: Hocheffiziente Speicherverwaltung.  Insgesamt das ist die schnellste Option mit konsistenten Ergebnissen allgemein.

Gewinner: ZuluOpenJDK - Hocheffiziente Speicherverwaltung und der höchste Durchsatz (Throughput).

Ergebnisse mit Marlin:

Allgemein Marlin hat den Durchsatz (Throughput) erhöht und die Bearbeitungszeit verbessert. Das ZuluJDK hat Marlin als Rendering Engine by default. 

Lizenzierung:

	100% Open Source	Commercial Support
Oracle JDK
Zulu JDK		Enterprise Version
Redhat JDK
AdoptJDK

Quelle: https://www.azul.com/products/zulu-enterprise/jdk-comparison-matrix/

Garbage Collector:

To display in a cmd: java -XX:+PrintCommandLineFlags -version

1. Oracle JDK (jdk1.8.0_181) - ParallelGC
2. Red hat OpenJDK (1.8.0.242-3.b08) - ParallelGC
3. AdoptOpenJDK (jdk8u242-b08) - ParallelGC
4. Azul Zulu JDK (1.8.0_242) - ParallelGC

Die Beschreibung der verschiedenen Typen des GCs: https://javapapers.com/java/types-of-java-garbage-collectors/ 

Parallel GC -  throughput GC. It works by freezing all the application threads while performing GC (multiple threads)

Serial GC - Good for the single-threaded environments. It works by freezing all the application threads while performing GC (Unlike Parallel GC, it uses a single thread)

CMS GC [Concurrent Mark Sweep] - uses multiple threads to scan the heap memory to mark instances for eviction and then sweep the marked instances. In comparison with parallel GC, CMS uses more CPU to ensure better application throughtput. If you can allocate more CPU for better performance then CMS garbage collector is the preferred choice over the parallel collector.

G1 GC -  for large heap memory areas. It separates the heap memory into regions and does collection within them in parallel.

testdoc_rendering_pixel.png (1 page) - verschidene GC

Ergebnisse über GCs:

Theorie: If you can allocate more CPU for better performance then CMS garbage collector is the preferred choice over the parallel collector. 

Tools:

JMH Benchmarks (Java Microbenchmark Harness)

Yourkit

Visualisator JMH Benchmarks https://jmh.morethan.io/