Final RFR: 8005232 (JEP-149) Class Instance size reduction

Aleksey Shipilev aleksey.shipilev at
Wed Jan 9 12:19:13 UTC 2013

Good stuff.

On 01/07/2013 02:46 AM, David Holmes wrote:

Sorry for obnoxious first-time reviewer questions:
 a) I think the CAS loop in newReflectionData() is misleading in its
reuse of the parameters. Can we instead inline it? Or, can we read the
fields for $reflectionData and $classRedefinedCount, with no parameters
 b) Had we considered filling up the complete ReflectionData eagerly on
first access? This will make ReflectionData completely final. I would
guess this goes against the per-use laziness?
 c) What's the merit of using Unsafe instead of field updaters here?
(Avoiding the dependency on j.u.c?)
 d) I think the code can be further simplified if we stick with
reflectionData() returning non-null object all the time, and check for
useCaches instead in the usages, at the expense of creating the methods
which actually get the reflection data.
 e) Should useCaches be final? That will allow aggressive optimizations
for (c).

> This is a saving of 7 reference fields ie. 28 bytes, resulting in a new
> Class instance size of 80 bytes. This saves a further 4 bytes due to the
> fields being 8-byte aligned without any need for padding. So overall we
> save 32 bytes per class instance.

Shameless promotion follows. This tool [1] should help to estimate the
class layout in the face of object alignment, compressed references,
paddings, alignment and whatnot.



More information about the core-libs-dev mailing list