Compressed object pointers in Hotspot VM

Currently I'm doing rather interesting project, implementing 32-bit Java object pointers in 64-bit versions of Hotspot. It allows significant space savings, performance boost and is also fun coding. The only disadvantage is limited addressable heap (~32G with default object alignment, more with bigger alignment).

Hardest part was to fit non-trivial encoding scheme into Hotspot concept of oops (ordinary object pointers), which are exactly that - direct pointers to objects, without compromising design sanity or performance, and also keeping single JVM binary for both compressed and not compressed case. Typical Java object in VM heap looks like this:

 -------------------------------------------------------------
| mark word | klass word |  potentially reordered java fields |
 -------------------------------------------------------------
and every Java field is accessed using offset from start of the object. For current design of compressed oops I decided to only use compressed scheme for fields accessible via computable offsets (i.e. Java object fields and object array elements). It saved me from rewriting of a lot of assembly code in the interpreter (Hotspot has optimized assembly interpreter).

Before this project getting of object field from Java object obj on C++ was semantically equivalent to:

oop get_oop(oop obj, int offset) {
  return \*(oop\*)((char\*)obj+offset);
}
and oop was something equivalent to intptr_t.

With 32-bit object pointers we need to have additional encoding/decoding code around access to the data, if we need to get direct pointer. Pretty natural encoding is the following:

oop = (uint)(((uintptr_t)(raw_obj - java_heap_base)) >> 3)
as Java objects known to be word aligned in Hotspot. If we'll force bigger alignement, we can address bigger heaps, at the price of potential holes between objects. Such encoding may, at least in unmodified form, isn't chunked heap friendly, but we don't support in Hotspot for several other reasons anyway.

There are couple ways to implement fast encoding/decoding for this encoding, while main problem being java_heap_base. We could either assign a register to it (most 64-bit architectures have enough registers), or use some "magical values" for heap base, so that computation of encoding/decoding routine could be made in a few machine code instructions. Update: actually we tried both approaches, and register in the base seems to be more flexible, although magic base approach leaves one more register to compiler's register allocator

Comments:

Hi Nikolay, Pointer compression sounds great! When can we expect this to appear in an openjdk-build? I'll try it at once. Thanks Anders

Posted by Anders on June 10, 2007 at 11:27 AM MSD #

Being rather major VM change it needs careful performance testing and tuning - that's what I'm working on right now. So sorry, no exact dates yet.

Posted by nike on June 14, 2007 at 09:26 AM MSD #

Post a Comment:
  • HTML Syntax: NOT allowed
About

nike

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today