What I had in mind:

Some GC-ed languages use an object representation where the "object" is split
into a header of, say, 8 to 16 bytes, which itself contains a pointer to the
body, where the object's non-static fields, etc, are stored.  This permits
easier implementation of moving GC, and has other benefits for languages with
less crippled semantics than Java (e.g. dynamic resizing of objects, or
Smalltalk's #become: operation).

There has been some research on the benefits of splitting objects so that their
frequently used fields are stored separately from their less frequently used
ones.  That has the benefit that more of the /useful/ data will fit into the
data caches (on-chip, or wherever) so the program on the whole may run faster
(at the cost that infrequently used fields take longer to access).

It may be worth splitting large arrays into "pages"; memory fragmentation can
be avoided by ensuring that there is a single, fixed, maximum size of any
allocation.

Incidentally, any/all the above might have greater benefit on a JVM designed to
make best use of a loosely-coupled multi-CPU architecture.  (Though whether it
would be actually /worth/ the effort of creating a special implementation for
such an application is a different question).  You point about RMI may reflect
the same  thinking -- if you can split an object so that you don't have to copy
/all/ of the object's state in order to use /any/ of its state, then you may
see a nett gain.

   -- chris