1 Ivan St. Ivanov Dmitry Alexandrov Martin ToshevOpenJDK Development Ivan St. Ivanov Dmitry Alexandrov Martin Toshev

2 Agenda The OpenJDK platform Development Process Architecture Overview

3 The OpenJDK Platform

4 The OpenJDK Platform Overview Adoption Contribution

5 Overview Who’s working on Open JDK?A free and open-source implementation of the Java Platform, Standard Edition GPL v2 for the VMs and GPL v2 + classpath exception for class libraries Major Linux distributions (Ubuntu, Fedora…) offer it as default JDK Who’s working on Open JDK? Oracle, IBM, SAP, RedHat, Goldman Sachs

6 Overview Who’s working on Open JDK?A free and open-source implementation of the Java Platform, Standard Edition GPL v2 for the VMs and GPL v2 + classpath exception for class libraries Major Linux distributions (Ubuntu, Fedora…) offer it as default JDK Who’s working on Open JDK? Oracle, IBM, SAP, RedHat, Goldman Sachs And many Java User Groups!

7 Adoption Adopt OpenJDK is an initiative helping Java communities to join in contributing to Java Types of contributions: Fix compiler warnings Write new tests or convert existing ones Build helpers Tutorials Major contributions to projects like Lambda and Jigsaw Some of the contribution will make it to the official OpenJDK project!

8 Contribution Starter level: Understand and build OpenJDK Test festsHelp promote using Lambdas Cleanup javac warnings Generify and coinify OpenJDK internals Automatic build of OpenJDK Other small enhancements

9 Contribution Intermediate level:Only after getting used to the ‘patch’ process Pick up a project to contribute Jigsaw and Penrose Nashorn Some other JDK Enhancement Proposal (JEP) Always consult the mailing lists!

10 Contribution Advanced level: Find and eliminate memory leaksPerformance improvements Concurrency testing Some new projects: Coroutines in Java Preparation for Tuples Value types Javadoc overhaul

11 Contribution Contribution targets: OpenJDK groups: OpenJDK projects:Collection of participants sharing common interests Longer living than projects Examples: HotSpot, Security, JMX, Core Libraries OpenJDK projects: Produce specific artifacts Must be sponsored by one or more Groups Examples: Coin, Lambda, New I/O, Jigsaw Groups -> Projects ->

12 Contribution Communication channels: Mailing lists IRC channelPreferable: announce, discuss and group/project mailing lists IRC channel Wiki pages Blog aggregator Mailing lists -> Wikis -> https://wiki.openjdk.java.net/dashboard.action, https://java.net/projects/adoptopenjdk/pages/AdoptOpenJDK IRC -> Blog aggregator ->

13 Contribution Contribution allows to: move Java forwardgive back something to the platform help our JUG gain its own identity and focus acquire new knowledge

14 Contribution Contribution allows to: move Java forwardgive back something to the platform help our JUG gain its own identity and focus acquire new knowledge have some fun 

15 Development Process

16 Development Process The community Becoming a contributorThe source tree Development environment

17 The community

18 The community General roles:Participant - may propose changes and participate in discussions Contributor - may submit changes and participate in a project or a group OpenJDK member - may propose new groups and may lead a group OpenJDK Lead - leads JDK release projects General roles: Participant - subscribed to one or more mailing lists; may post messages and make small contributions Contributor - has signed (or employer has signed) the Oracle Contributor Agreement; may submit patches, propose projects, and participate in groups and projects; OpenJDK member - has been nominated and elected by vote of existing OpenJDK Members; may propose new groups and may lead a group may vote on new OpenJDK members may vote on new at-large members of the governing board OpenJDK Lead appointed by Oracle leads JDK release projects is a member of the governing board

19 The community Group roles:Group Member - has write access to the group's web content and file repositories Group Lead - responsible for directing and coordinating the group's activities; Group Roles: Group Member - elected by other group members may nominate other contributors to be elected a group member has write access to the group's web content and file repositories Group Lead - approved by group members and ratified by governing board; responsible for directing and coordinating the group's activities; has the authority to sponsor projects; obligation to act as contact point for group and look after content; obligation to publish a quarterly report on activities on the group

20 The community Project roles:Author - may create change sets but may not push them directly Commiter - may create and push change sets Reviewer - reviews and approves change sets Project Lead - responsible for directing and coordinating the project's activities Project Roles: Author - self-nominated contributor appointed by project lead; may create change sets but may not push them directly Commiter - nominated and approved by other commiters; may create and push change sets; may vote on new commiters Reviewer - an experienced commiter nominated & elected by other reviewers in the project; role only exists in projects where project lead has designated a reviewer role is required and only for change sets the project lead designates; reviews and approves change sets Project Lead - A commiter for the project responsible for directing and coordinating the project's activities; considered a reviewer and maintain reviewer status; elected by sponsoring group lead(s); has full authority over all technical matters related to project; has the authority to appoint and remove authors; obligation to act as a contact point for project and manage content; obligation to publish a quarterly report on activities on the project

21 Becoming a contributorSign OCA (Oracle Contributor Agreement) – specify OpenJDK as the project and your java.net user as the username Send the signed OCA to Find some interesting bug or enhancement (RFE) to work on from bugs.sun.com

22 Becoming a contributorYou may subscribe to a particular mailing list of interest – list is available at mail.openjdk.java.net/mailman/listinfo Discuss any changes you want to make in the appropriate mailing list using the format: :

23 Becoming a contributorAdd a proposed code change (patch) to the discussion using any of the following commands: hg export -g hg diff -g If applicable attach JTReg tests to the suggested changeset

24 The source tree Repositories: root (infrastructure files and scripts)hotspot (Java Virtual Machine – JVM) langtools (the javac compiler and other tools) jdk (class libraries) jaxp (JAXP API) jaxws (JAX-WS API) corba (CORBA API) nashorn (JavaScript Engine) overview: overview: https://wiki.openjdk.java.net/dashboard.action overview: hgview

25 Development EnvironmentDevelopment environment is already available (see references): Virtual Box VM 2-4 CPU 3.0 GB RAM 20 GB HDD OS: Ubuntu 12.04 IDE: Eclipse (JDT, CDT) DVCS: Mercurial

26 Development EnvironmentFull OpenJDK build make all (about 1 hour) Targeted project build make [jdk, jdk-only,corba..] ANT (Build.xml) overview: development environment

27 Development Environmentjtreg is the test harness used by the OpenJDK test framework Use targets from $REPO_DIR/test/Makefile to run tests For example: make TEST="jdk_lang jdk_net" make jdk_all overview: development environment (source code, building projects and running tests)

28 Architecture Overview

29 Architecture OverviewThe compiler (javac) The runtime Code walkthrough

30 The Compilter Compilation Flow:Main entry point for the GCJ (GNU Compiler for Java): com.sun.tools.javac.main.JavaCompiler Compilation flow: 1) All the source files specified on the command line are read, parsed into syntax trees, and then all externally visible definitions are entered into the compiler's symbol tables. 2) All appropriate annotation processors are called. If any annotation processors generate any new source or class files, the compilation is restarted, until no new files are created (for example annotations used by various aspect-oriented tools that perform code generation benefit from this flow). 3) Finally, the syntax trees created by the parser are analyzed and translated into class files. During the course of the analysis, references to additional classes may be found. The compiler will check the source and class path for these classes; if they are found on the source path, those files will be compiled as well, although they will not be subject to annotation processing.

31 The Compiler A very simple abstract file systems is used by the various tools of the Java ecosystems (including javac): javax.tools.JavaFileManager Error messages during compilation are reported by means of: com.sun.tools.javac.util.Log

32 The Compiler Logger pipeline:(source: JavaOne, Maurizio Cimadamore & Jonathan Gibbons, Sun Microsystems) 1) The compiler pipeline pushes diagnostics to Log. 2) DiagnosticFormatter controls the way in which diagnostics are rendered by javac.

33 The Compiler The lexer (maps source text into a stream of tokens) is provided by: com.sun.tools.javac.parser.Scanner The parser (converts the stream of tokens into one or more syntax trees) is provided by: com.sun.tools.javac.parser.JavacParser The classes in the com.sun.source.tree package provide public read access to the syntax trees.

34 The Compiler Annotation processing is handled by:com.sun.tools.javac.processing.JavacProcessingEnvironment During the ‘analyze and generate’ phase a number of visitors are used to modify the syntax tree and generate the class files. Relevant classes used in the ‘analyze and generate phase’ are: Attr - names, expressions and other elements within the syntax tree are resolved and associated with the corresponding types and symbols. Many semantic errors may be detected here. Flow - flow analysis is used to check for definite assignment to variables, and unreachable statements, which may result in additional errors. TransTypes- code involving generic types is translated to code without generic types, using TransTypes. Lower - “syntactic sugar" is processed, using Lower, which rewrites syntax trees to eliminate particular types of subtree by substituting equivalent, simpler trees. This takes care of nested and inner classes, class literals, assertions, foreach loops, and so on. For each class that is processed, Lower returns a list of trees for the translated class and all its translated nested and inner classes. Gen - code for methods is generated by Gen, which creates the Code attributes containing the bytecodes needed by a JVM to execute the method. If that step is successful, the class is written out by ClassWriter. To save memory, references to these parts of the tree and symbols will be nulled out, to allow the memory to be recovered by the garbage collector.

35 The Runtime The Java runtime environment (virtual machine) is provided by the hotspot project. Provides : bytecode execution - using an interpreter, two runtime compilers or On-Stack Replacement storage allocation and garbage collection runtimes - start up, shut down, class loading, threads, interaction with OS and others - About lines of code - The HotSpot continually analyzes the program's performance for "hot spots". - Sun's JRE features two virtual machines, one called Client and the other Server. The Client version is tuned for quick loading. It makes use of interpretation. The Server version loads more slowly, putting more effort into producing highly optimized JIT compilations, that yield higher performance. Both VMs compile only often-run methods, using a configurable invocation-count-threshold to decide which methods to compile.

36 The Runtime ArchitectureEach thread of execution has the following components: Program Counter (PC) Address of the current instruction (or opcode) unless it is native. If the current method is native then the PC is undefined. All CPUs have a PC, typically the PC is incremented after each instruction and therefore holds the address of the next instruction to be executed. The JVM uses the PC to keep track of where it is executing instructions, the PC will in fact be pointing at a memory address in the Method Area. Stack Each thread has its own stack that holds a frame for each method executing on that thread. The stack is a Last In First Out (LIFO) data structure, so the currently executing method is at the top of the stack. A new frame is created and added (pushed) to the top of stack for every method invocation. The frame is removed (popped) when the method returns normally or if an uncaught exception is thrown during the method invocation. The stack is not directly manipulated, except to push and pop frame objects, and therefore the frame objects may be allocated in the Heap and the memory does not need to be contiguous. Native Stack Not all JVMs support native methods, however, those that do typically create a per thread native method stack. If a JVM has been implemented using a C-linkage model for Java Native Invocation (JNI) then the native stack will be a C stack. In this case the order of arguments and return value will be identical in the native stack to typical C program. A native method can typically (depending on the JVM implementation) call back into the JVM and invoke a Java method. Such a native to Java invocation will occur on the stack (normal Java stack); the thread will leave the native stack and create a new frame on the stack (normal Java stack). Stack Restrictions A stack can be a dynamic or fixed size. If a thread requires a larger stack than allowed a StackOverflowError is thrown. If a thread requires a new frame and there isn’t enough memory to allocate it then an OutOfMemoryError is thrown.

37 The Runtime Thread stack

38 The Runtime Stack frameA new frame is created and added (pushed) to the top of stack for every method invocation. The frame is removed (popped) when the method returns normally or if an uncaught exception is thrown during the method invocation. Each frame contains: Local variable array Return value Operand stack Reference to runtime constant pool for class of the current method

39 The Runtime Class Data A compiled class file consists of the following structure: ClassFile { u4 magic; u2 minor_version; u2 major_version; u2 constant_pool_count; cp_info contant_pool[constant_pool_count – 1]; u2 access_flags; u2 this_class; u2 super_class; u2 interfaces_count; u2 interfaces[interfaces_count]; u2 fields_count; field_info fields[fields_count]; u2 methods_count; method_info methods[methods_count]; u2 attributes_count; attribute_info attributes[attributes_count]; }

40 The Runtime Non-Heap MemoryObjects that are logically considered as part of the JVM mechanics are not created on the Heap. The non-heap memory includes: Permanent Generation that contains the method area and interned strings Code Cache used for compilation and storage of methods that have been compiled to native code by the JIT compiler The method area stores per-class information such as: Class Loader Reference Run Time Constant Pool Numeric constants Field references Method References Attributes Field data (per field) Name Type Modifiers Method data (per method) Return Type Parameter Types (in order) Method code (Per method) Bytecodes Operand stack size Local variable size Local variable table Exception table (per exception handler - start point, end point, PC offset for handler code, constant pool index for exception class being caught)

41 The Runtime Heap MemoryThe Heap is used to allocate class instances and arrays at runtime. Arrays and objects can never be stored on the stack because a frame is not designed to change in size after it has been created. The frame only stores references that point to objects or arrays on the heap. Unlike primitive variables and references in the local variable array (in each frame) objects are always stored on the heap so they are not removed when a method ends. Instead objects are only removed by the garbage collector. To support garbage collection the heap is divided into three sections: Young Generation - Often split between Eden and Survivor Old Generation (also called Tenured Generation) Permanent Generation Objects and Arrays are never explicitly de-allocated instead the garbage collector automatically reclaims them. Typically this works as follows: 1) New objects and arrays are created into the young generation 2) Minor garbage collection will operate in the young generation. Objects, that are still alive, will be moved from the eden space to the survivor space. 3) Major garbage collection, which typically causes the application threads to pause, will move objects between generations. Objects, that are still alive, will be moved from the young generation to the old (tenured) generation. 4) The permanent generation is collected every time the old generation is collected. They are both collected when either becomes full. mark word - The first word of every object header. Usually a set of bitfields including synchronization state and identity hash code. May also be a pointer (with characteristic low bit encoding) to synchronization related information. During GC, may contain GC state bits. klass pointer - The second word of every object header. Points to another object (a metaobject) which describes the layout and behavior of the original object. For Java objects, the "klass" contains a C++ style "vtable". Note that both Java objects and VM-internal objects have a common object header format. The Young Generation The young generation must support fast allocation, but we expect most of those objects to become unreachable fairly quickly. We would like not to have to expend any effort on the unreachable objects, since there are so many of them. So when our young generations need to be collected, we identify the lreachable objects in them and copy them out of the young generation. Once we've copied out the reachable objects, the objects remaining in the young generation are unreachable, and the space for them can be recovered without attention to each individual unreachable object. This operation of copying the reachable objects out of a generation we call “scavenging”, so we often refer to our young generation collectors as “scavengers”. An advantage of scavenging is that it is fast. A disadvantage is that it requires room of a second copy of all the reachable objects from the scavenged generation. The Old Generation Once objects have been scavenged out of the young generation we expect them to remain reachable for at least a while, and to reference and be referenced by other objects that remain reachable. To collect the space in the old generation we need algorithms that can't depend on high density of unreachable objects. In particular we can't count on having enough space to scavenge such objects somewhere else. Copying objects in the old generation can be expensive, both because one has to move the objects, and because one has to update all the references to the object to point to the new location of the object. On the other hand, copying objects means that one can accumulate the recovered space into one large region, from which allocation is faster (which speeds up scavenging of the young generation), and allows us to return excess storage to the operating system, which is polite. The Permanent Generation In addition to the objects created by the Java application, there are objects created and used by the HotSpot virtual machine whose storage it is convenient to have allocated and recovered by the storage manager. To avoid confusing things, such objects are allocated in a separate generation, the so-called “permanent” generation. In fact, the objects in it are not “permanent”, but that's what it has been called historically. For example, information about loaded classes is stored in the permanent generation, and recovered when those classes are no longer reachable from the application.

42 The Runtime Three phases of class-loading: Loading LinkingInitialization Loading: finding and importing the binary data for a type Linking: performing verification, preparation, and (optionally) resolution Verification: ensuring the correctness of the imported type Preparation: allocating memory for class variables and initializing the memory to default values Resolution: transforming symbolic references from the type into direct references. Initialization: Invoking Java code that initializes class variables to their proper starting values.

43 The Runtime Execution engine: while(true) {bytecode b = bytecodeStream[pc++]; switch(b) { case iconst_1: push(1); break; case iload_0: push(local(0)); break; case iadd: push(pop() + pop()); break; }

44 The Runtime Execution engine: while(true) {bytecode b = bytecodeStream[pc++]; switch(b) { case iconst_1: push(1); break; case iload_0: push(local(0)); break; case iadd: push(pop() + pop()); break; } } NOT that simple …

45 The Runtime Different execution techniques: interpretingjust-in-time (JIT) compilation adaptive optimization (determines "hot spots" by monitoring execution) The bytecode is first interpreted while the JIT is translating it in the background. Once the JIT compilation is complete, the JVM switches to using that code instead of the interpreter. 

46 The Runtime Simple JIT compilation flow (performed during normal bytecode execution): 1) bytecode is turned into a graph 2) the graph is turned into a linear sequence of operations that manipulate an infinite loop of virtual registers (each node places its result in a virtual register) The bytecode is first interpreted while the JIT is translating it in the background. Once the JIT compilation is complete, the JVM switches to using that code instead of the interpreter. 

47 The Runtime Simple JIT compilation flow (performed during normal bytecode execution): 3) physical registers are allocated for virtual registers (the program stack might be used in case virtual registers exceed physical registers) 4) code for each operation is generated using its allocated registers

48 The Runtime Typical execution flow (when using the java/javaw launcher): Parse the command line options Establish the heap sizes and the compiler type (client or server)  Establish the environment variables such as CLASSPATH If the java Main-Class is not specified on the command line fetch the Main-Class name from the JAR's manifest Create the VM using JNI_CreateJavaVM in a newly created thread (non primordial thread) JNI_CreateJavaVM The JNI invocation method performs, the following: Ensures that no two threads call this method at the same time and that no two VM instances are created in the same process. Noting that a VM cannot be created in the same process space once a point in initialization is reached, “point of no return”. This is so because the VM creates static data structures that cannot be re-initialized, at this time. Checks to make sure the JNI version is supported, and the ostream is initialized for gc logging. The OS modules are initialized such as the random number generator, the current pid, high-resolution time, memory page sizes, and the guard pages. The arguments and properties passed in are parsed and stored away for later use. The standard java system properties are initialized. The OS modules are further created and initialized, based on the parsed arguments and properties, are initialized for synchronization, stack, memory, and safepoint pages. At this time other libraries such as libzip, libhpi, libjava, libthread are loaded, signal handlers are initialized and set, and the thread library is initialized. The output stream logger is initialized. Any agent libraries (hprof, jdi) required are initialized and started. The thread states and the thread local storage (TLS), which holds several thread specific data required for the operation of threads, are initialized. The global data is initialized as part of the I phase, such as event log, OS synchronization primitives, perfMemory (performance memory), chunkPool (memory allocator). At this point, we can create Threads. The Java version of the main thread is created and attached to the current OS thread. However this thread will not be yet added to the known list of the Threads. The Java level synchronization is initialized and enabled. The rest of the global modules are initialized such as theBootClassLoader, CodeCache, Interpreter, Compiler, JNI, SystemDictionary, and Universe. Noting that, we have reached our “point of no return”, ie. We can no longer create another VM in the same process address space. The main thread is added to the list, by first locking the Thread_Lock. The Universe, a set of required global data structures, is sanity checked. The VMThread, which performs all the VM's critical functions, is created. At this point the appropriate JVMTI events are posted to notify the current state. The following classes java.lang.String, java.lang.System,java.lang.Thread, java.lang.ThreadGroup,java.lang.reflect.Method, java.lang.ref.Finalizer,java.lang.Class, and the rest of the System classes, are loaded and initialized. At this point, the VM is initialized and operational, but not yet fully functional. The Signal Handler thread is started, the compilers are initialized and the CompileBroker thread is started. The other helper threads StatSampler and WatcherThreads are started, at this time the VM is fully functional, the JNIEnv is populated and returned to the caller, and the VM is ready to service new JNI requests.

49 The Runtime Typical execution flow (when using the java/javaw launcher): 6. Once the VM is created and initialized, load the Main- Class 7. Invoke the main method in the VM using CallStaticVoidMethod 8. Once the main method completes check and clear any pending exceptions that may have occurred and also pass back the exit status 9. Detach the main thread using  DetachCurrentThread , by doing so we decrement the thread count so the DestroyJavaVM can be called safely DestroyJavaVM This method can be called from the launcher to tear down the VM, it can also be called by the VM itself when a very serious error occurs. The tear down of the VM takes the following steps: Wait until we are the last non-daemon thread to execute, noting that the VM is still functional. Call java.lang.Shutdown.shutdown(), which will invoke Java level shutdown hooks, run finalizers if finalization-on-exit. Call before_exit(), prepare for VM exit run VM level shutdown hooks (they are registered through JVM_OnExit()), stop the Profiler,StatSampler, Watcher and GC threads. Post the status events to JVMTI/PI, disable JVMPI, and stop the Signal thread. Call JavaThread::exit(), to release JNI handle blocks, remove stack guard pages, and remove this thread from Threads list. From this point on we cannot execute any more Java code. Stop VM thread, it will bring the remaining VM to a safepoint and stop the compiler threads. At a safepoint, care should that we should not use anything that could get blocked by a Safepoint. Disable tracing at JNI/JVM/JVMPI barriers. Set _vm_exited flag for threads that are still running native code. Delete this thread. Call exit_globals(), which deletes IO and PerfMemoryresources. Return to caller.

50 Code Walkthrough COMPILER: Official API:javax.annotation.processing - Facilities for declaring annotation processors and for allowing annotation processors to communicate with an annotation processing tool environment javax.lang.model (including subpackages) - classes and hierarchies of packages used to model the Java programming language javax.tools - provides interfaces for tools which can be invoked from a program, for example, compilers Supported API: com.sun.source (including subpackages) - representation of the compiler syntax trees com.sun.tools.javac - the javac main program and command-line entry point provides supported API for very simple invocation of the compiler Internal API and implementation classes: com.sun.tools.javac.api - Implementation of JavaCompiler and other API in javax.tools. com.sun.tools.javac.code - representation of the semantic elements of a Java program, such as symbols, scopes and types, implementing API in javax.lang.model.* com.sun.tools.javac.comp - primary processing phases for the compiler, such as attribution, flow analysis, "desugaring" and erasure com.sun.tools.javac.file - access to the native file system, including the implementation of javax.tools.StandardFileManager com.sun.tools.javac.nio - access to the native file system using the java.nio.file API, including JavacPathFileManager com.sun.tools.javac.jvm - classes for reading and writing class files, and the code generation phase of the compiler com.sun.tools.javac.main - main driver code for any compilation. It provides option decoding and sequences through the various steps for compilation com.sun.tools.javac.model - additional implementation classes for javax.lang.model.* com.sun.tools.javac.parser - read Java source code to generate syntax trees com.sun.tools.javac.processing - implementation classes for annotation processing API defined injavax.annotation.processing.* com.sun.tools.javac.resources - resource files for localized messages and version info com.sun.tools.javac.tree - representation and utility classes for the compiler's syntax trees, implementing API in com.sun.source.* com.sun.tools.javac.util - basic utility classes, including support for reporting diagnostics Demo: modifying the compiler: add the # operators that is a synonym to != (in the TokenKind class) add precedence for the operator (in the opPrec() method of the TreeInfo class) modify the constructor of TreeInfo – add the operator to the opname array add support for the operator in the textual representation of the AST (in the operatorName() method of the Pretty class) add the new operator to the list of system names recognizable by the compiler (in the Symtab) class – duplicate the lines for the != operator

51 What’s next ? Adopt OpenJDK @ OpenFestMani Sarkar, November 2nd, 14:00, Interpred Official unofficial OpenJDK dinner To be announced Adopt Java2Days December 4th- December 5th , IEC

52 Q&A

53 References OpenJDK Contribution OpenJDK Development Environment OpenJDK Development Environment https://github.com/martinfmi/openJDK_Ubuntu_12.04_Eclipse Mercurial Quick Start

54 References Adopt OpenJDK wikihttps://java.net/projects/adoptopenjdk/pages/AdoptOpenJDK Video: OpenJDK Governance and Development Process Overview

55 References The OpenJDK Developers' Guide The Java programming language compiler group The Hacker's Guide to Javac

56 References JavaOne: Java Programming Language Tools in JDK Release 7https://blogs.oracle.com/mcimadamore/resource/09J1_langtools_all.pdf How to Modify javac, JavaMagazine, August, 2012

57 References Hotspot Internals FOSDEM 2007, Java Hotspot Virtual Machinehttps://wiki.openjdk.java.net/display/HotSpot/Main FOSDEM 2007, Java Hotspot Virtual Machine

58 References Memory Management in the Java Hotspot Virtual Machine The Architecture of the Java Virtual Machine

59 References JVM Internals Understanding JVM Internals Understanding JVM Internals