Investigate downsizing average object size by removing (or downsizing) the klass word from the oopDesc layout.

DRAFT DRAFT DRAFT

The klass word in the object header points to the internal type metadata for the object. This word can be 64 bits, or if compressed, 32 bits.

There are well-known techniques for reducing the average size of this field, by assigning short encodings for a number of "favored" or "well known" klass pointers. A typical Java heap has a small number of types that contribute the bulk of all objects. This means that an 8-bit number is often enough to address the klasses of 90% of the objects in the heap. (Also, a 4-bit number will often cover over 50% in the heap, while a 10-bit number will often cover over 98%.)

Therefore, if we could find just a few extra bits to store a "common klass" encoding in an object, most of the klass header could be omitted. In doing this density of the heap would go up by a significant factor, basically (1+3/S), where S is the average object size; since S is typically something like 30-40 bytes (except for arrays), the overhead of klass can often be a significant percentage.

For course, after the first 2^N code points are used to encode common klasses (where N is some number like 8 or 10) then a larger klass field will be required in objects of subsequently created klasses. Since object layout is performed when a class is loaded, it is reasonable to allocate extended (32-bit) klass fields only in those later types which do not acquire a short (8-bit or 10-bit) klass index.

If non-compressed oops are in use, and if a decision is made to color managed pointers, and if N bits (N = 8 or 10 or even 16) are available as ignored color bits in the 64-bit pointer, then the klass bits (for a favored klass) can also be hoisted into every reference to that object. This would realize the very old idea of a tagged pointer to an object.

This scheme can be combined with JDK-8198331 (mark word removal). The first 16 bits of an object could be allocated to a hyper-compressed klass pointer plus a few mark-word control bits (to signal the presence of a lock and/or hash code). The 32-bit word containing those 16 bits could be allocated to a full klass pointer (or index), but in most cases the other 16 bits would be available for ordinary instance fields or other metadata.