Java 7 chapter 1: The Virtual Machine

To prepare for the arrival of the Dolphin, I will indulge in some research entitled "What's new in Java 7". The story will consist of 5 chapters: the vm, the language, the core, the client and the Web. First came the change to the virtual machine.

CompressedOops
OOP is an “ordinary object pointer”, and it’s length is usually similar to the length of the native operating system pointer. Increasing the length from 32 to 64 bits will cause the heap in a 32-based program (running on a 64-bit system) to expand by 50%. Memory is cheap, but bandwidth and cache is expensive, and it is should not be very costly to port applications a new platform. Using a 64 bit vm and the UseCompressedOops flag will keep addressing overhead similar to that of 32 bit systems at the cost of cpu cycles.

Garbage First GC (“G1”)
Replacement for Concurrent-Mark-Sweep GC, but still “generational”. CMS divides memory into young generation (eden, survivor) and and old generation. Move live object into a more “persistent” generation. Stops the world to do complete collections. G1 divides memory into small “regions”, and these are labeled “young” or “old”. During a GC, those objects who are “live” in a region, will be compacted with other “live” objects in another region, depending on their age. Each region has a “remembered set”, which contains all external references to this region. This reduces the need to pause the world to mark.

G1 is a server-style garbage collector, targeted for multiprocessor- and large memory systems. It aims at being more predictable than CMS. It’s also available in 6u14.

JSR 292: The Da Vinci Machine Project
The JVM should be extended with general support of languages other than Java, and in particular dynamically typed languages. Such language implementers have observed a range of painful aspects of the byte code language, and this projects aims to remove those in a general manner. The noteworthy suggestions is: dynamic invocation, continuations, tail-calls and interface injection. The JSR specifically targets dynamic invocation and hot class modification. Today dynamic languages produces a lot of different options for signatures that all have to be stored in permgen space. This is very inefficient, and one should be able to narrow down these options at runtime.