The prior work on the subject by Adl-Tabatabai propose a straight forward
compression scheme for addressing the memory usage in 64-bit Java virtual
machines. They represent 64-bit pointers as 32-bit offsets from a base
address of a contiguous memory region. Dereferencing or decompressing a
pointer then involves adding the 32-bit offset to a base address yielding a
64-bit virtual address. Reverse, compressing a 64-bit virtual address into
a 32-bit offset requires substracting the 64-bit address from the base
address; the lower 32 bits are then stored. A similar approach was
proposed by Lattner and Adve for compressing pointers in linked data
structures.
The fact that 64-bit virtual addresses are represented as 32-bit offsets
from a base address implies that this pointer compression technique is
limited to Java programs that consume less than 4GB of storage. If a
Java program allocates more than 4GB of memory, the virtual machine
has to revert to the 64-bit pointer representation. This could for example
be done by setting the maximum heap size through a command line
option: if the maximum heap size is larger than 4GB, uncompressed
pointers are used; if smaller than 4GB, compressed pointers are used.
Fig. 1. Illustrating the basic idea of object-relative addressing (on the right)
compared against the traditional 64-bit addressing (on the left).
Adl-Tabatabai apply their pointer compression method to both vtable
pointers and pointers to other Java objects, so called object references.
The 32-bit object references are then relative offsets to the heap’s base
address; the 32-bit vtable pointers are relative offsets to the vtable
space’s base address.
We focus on compressing object references and do not address vtable
pointer compression. The reason is that vtable pointers are not that big
of an issue when it comes to pointer compression. The 32-bit vtable
pointer offsets are highly likely to be sufficient even for programs that
allocate very large amounts of memory; it is highly unlikely to require
more than 4GB of memory for allocating vtables. In other words, the
pointer compression method by Adl-Tabatabai et al. is likely to work
properly when applied to vtable pointers. Moreover, recent work by
Venstermans has proposed a technique that completely eliminates the
vtable pointer from the object header through typed virtual addressing.
We also refer to the related work section of this paper for a discussion
on object header reduction techniques.
compression scheme for addressing the memory usage in 64-bit Java virtual
machines. They represent 64-bit pointers as 32-bit offsets from a base
address of a contiguous memory region. Dereferencing or decompressing a
pointer then involves adding the 32-bit offset to a base address yielding a
64-bit virtual address. Reverse, compressing a 64-bit virtual address into
a 32-bit offset requires substracting the 64-bit address from the base
address; the lower 32 bits are then stored. A similar approach was
proposed by Lattner and Adve for compressing pointers in linked data
structures.
The fact that 64-bit virtual addresses are represented as 32-bit offsets
from a base address implies that this pointer compression technique is
limited to Java programs that consume less than 4GB of storage. If a
Java program allocates more than 4GB of memory, the virtual machine
has to revert to the 64-bit pointer representation. This could for example
be done by setting the maximum heap size through a command line
option: if the maximum heap size is larger than 4GB, uncompressed
pointers are used; if smaller than 4GB, compressed pointers are used.
Fig. 1. Illustrating the basic idea of object-relative addressing (on the right)
compared against the traditional 64-bit addressing (on the left).
Adl-Tabatabai apply their pointer compression method to both vtable
pointers and pointers to other Java objects, so called object references.
The 32-bit object references are then relative offsets to the heap’s base
address; the 32-bit vtable pointers are relative offsets to the vtable
space’s base address.
We focus on compressing object references and do not address vtable
pointer compression. The reason is that vtable pointers are not that big
of an issue when it comes to pointer compression. The 32-bit vtable
pointer offsets are highly likely to be sufficient even for programs that
allocate very large amounts of memory; it is highly unlikely to require
more than 4GB of memory for allocating vtables. In other words, the
pointer compression method by Adl-Tabatabai et al. is likely to work
properly when applied to vtable pointers. Moreover, recent work by
Venstermans has proposed a technique that completely eliminates the
vtable pointer from the object header through typed virtual addressing.
We also refer to the related work section of this paper for a discussion
on object header reduction techniques.
No comments:
Post a Comment