# JVM ## History - [A categorized list of all Java and JVM features since JDK 8 to 16](x-devonthink-item://5F62BC44-980E-44EE-A812-6B72EF7A05F6) - [Significant Changes in the JDK](https://docs.oracle.com/en/java/javase/18/migrate/significant-changes-jdk-release.html) ## Compiler - [Tiered Compilation](x-devonthink-item://B320DEB5-5B4A-48FF-B51E-3F3CCAC16640) - [[GraalVM]] - [debug information](https://readwise.io/reader/shared/01gnzpexrgksc578z7emdxnw0b) ## Memory Tuning - [Thread Local Allocation Buffers](https://shipilev.net/jvm/anatomy-quarks/4-tlab-allocation/) (TLAB) impact ### Containers - [JVM memory tuning in containers](x-devonthink-item://74A1B8B0-003A-49BF-B446-6E4FD5041C0B) - [use at least 2 cores and 2GB of memory in containers](x-devonthink-item://680520E8-7CE3-4FDA-A272-DB63789097BA) ^1cf9bf - based on what Java considers `os::is_server_class_machine()` - If the VM isn't "server class", will use Serial GC instead of G1 GC ### Large Pages From [Large Pages and Java](x-devonthink-item://CC6BB28C-2901-4607-A1A8-969D23B300AC) > Large pages, or sometimes huge pages, is a technique to reduce the pressure on the processors [TLB](https://en.wikipedia.org/wiki/Translation_lookaside_buffer) caches. To enable, use `-XX:+UseLargePages` JVM switch. But to work requires OS-specific tuning #### Linux Two options: Transparent Huge Pages and HugeTLB pages. > Both approaches have pros and cons and which one to choose depends on more than one aspect. THP is easier to setup and use, but you have more control when using HugeTLB pages. If latency is your biggest concern, you should probably go with HugeTLB pages since you will never stall waiting for the OS to free up enough contiguous memory. As an alternative you can configure the defrag option of THP to not stall if no large pages are available, but this might come with a throughput cost instead. If memory footprint is a concern THP is the better choice to avoid having to commit the whole Java heap up front. > Which type of large pages to use depends on the application and the environment, but in many cases just using any type of large pages will have a positive effect on performance. ##### Transparent Huge Pages - `always` - transparent huge pages are used automatically by any application. - `madvise` - transparent huge pages are only used if the application uses madvise() with the flag MADV_HUGEPAGE to mark that certain memory segments should be backed by large pages. - `never` ```bash echo "madvise" > /sys/kernel/mm/transparent_hugepage/enabled ``` The JVM has support to make use of THP when configured in `madvise` mode, but it needs to be enabled by using `-XX:+UseTransparentHugePages`. See [the Linux kernel docs on THP](https://www.kernel.org/doc/Documentation/vm/transhuge.txt) for defrag options and implications. ##### HugeTLB pages This type of large pages is pre-allocated by the OS and consume the physical memory used to back them. An application can reserve pages from this pool using mmap() with the flag MAP_HUGETLB. This is the default way to use large pages for the JVM on Linux and it can be enabled by either setting `-XX:+UseLargePages` or the specific flag `-XX:+UseHugeTLBFS`. When the JVM uses this type of large pages it commits the whole memory range backed by large pages up front3. This is needed to ensure that no other reservation depletes the pool of large pages allocated by the OS. This also means that there need to be enough large pages pre-allocated to back the whole memory range at the time of the reservation, otherwise the JVM will fall back to use normal pages. See [source article](x-devonthink-item://CC6BB28C-2901-4607-A1A8-969D23B300AC) for Linux configuration details. ### Time To Safepoint, pagefaulting rel:: [[Profiling]] rel:: [[async-profiler]] - [Analyzing long time to safepoint](x-devonthink-item://E0B49EA8-CEA8-4A29-AA0E-7C86AD3EE862) from page faulting ### ZGC Garbage Collector - [ZGC What's new in JDK17](x-devonthink-item://6CD91D23-39B3-47EA-958B-D1A468E9010F) ## Classfile ### Project Valhalla User-defined primitive types. #### [[2020-04-28]] [State of Valhalla](https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/03-vm-model.md) How primitive types are represented at the class and JVM layer. It also provides some overview of class-representation of JVM type in general. ## Tooling - [[Java Flight Recorder|JFR]] - [[JDK Mission Control|JMC]] - [[async-profiler]] ### Security Manager [How to trace filesystem access using the JVM Security Manager](x-devonthink-item://9499F5B7-D56F-41F0-B6F1-7A856503403A) ## GraalVM ### Tools - [Ideal Graph Visualizer](https://www.graalvm.org/tools/igv/) ## CLI Switches | switch | description | | ------------------- | --------------------------------------- | | `-Xinternalversion` | build details including architecture | | `-XshowSettings` | detailed version info and switches help | - [CompileCommand JVM option](x-devonthink-item://B5D2BC0C-1D3D-4252-80CD-84CD159F37BA) - also see [compiler control JEP165](https://openjdk.org/jeps/165) - [options explorer](https://chriswhocodes.com/) (by version) ## Foreign Function Interface - [State of FFI Java 2022](https://developer.okta.com/blog/2022/04/08/state-of-ffi-java) ([devonthink](x-devonthink-item://2648E098-2111-4F48-BBDE-271E03F2B1C1)) - Project Panama - [Project Panama for Newbies](https://foojay.io/today/project-panama-for-newbies-part-1/) - Foreign Function & Memory API - [JEP-412](https://openjdk.java.net/jeps/412) - First incubator in JDK 17 - [JEP-419](https://openjdk.java.net/jeps/419) - Second incubator in JDK 18 - [JEP-424](https://openjdk.java.net/jeps/424) - First preview expected in JDK 19 15 - [api link](https://docs.oracle.com/en/java/javase/19/core/foreign-function-and-memory-api.html#GUID-FBE990DA-C356-46E8-9109-C75567849BA8) - [java-native-benchmark](https://github.com/zakgof/java-native-benchmark/tree/12df7a56ed16c5d61967e15a915e87f60b9744de) - compares JNA, JNI, project panama, and [JNR](https://github.com/jnr/jnr-ffi)