-
Enhancement
-
Resolution: Fixed
-
P4
-
repo-lilliput
https://github.com/openjdk/lilliput/pull/13 changed nKlass encoding by increasing the Klass alignment gap to 512. Works fine and gives us a nKlass-value-point-to-class ratio of about 1.5:1, which means we get close to the goal of representing each class with a single value of nKlass without changing Klass to a fixed-sized Layout.
This has two disadvantages though, one of which is addressed by this issue. The obvious disadvantage is waste of alignment space. For normal programs this does not matter much: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class. We usually do that.
But for class-generation scenarios we often only have a single or very few objects per class, and much more classes, so the numbers don't add up anymore. Therefore a way should be found to use these alignment gaps for storing metadata.
The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace).
This has two disadvantages though, one of which is addressed by this issue. The obvious disadvantage is waste of alignment space. For normal programs this does not matter much: the average waste is 256 bytes per class, and if Lilliput saves 4 bytes per object, we break even if we create more than 64 objects per class. We usually do that.
But for class-generation scenarios we often only have a single or very few objects per class, and much more classes, so the numbers don't add up anymore. Therefore a way should be found to use these alignment gaps for storing metadata.
The simple solution is to save non-class metadata from the same class loader into these gaps. This works fine since much of our non-class metadata is very fine granular. Like sand into cracks, they settle into the gaps. And it is not even complicated since we already have the machinery (the descendant of Coleen's original dark-matter-prevention-structure that we use to manage prematurely deallocated metaspace).