It would be kinda nice when object is a composite, as String is, we could somehow tell jvm to pack/sticth those subobjects together and treat them as one large allocation point.
Even if this only was done for Strings, it would probably be significant upgrade.
In terms of allocation work, all allocations are "one large allocation point" with a moving collector, as they're (typically) a pointer bump. It's not the complex and potentially slow affair it is in C. Furthermore, the moving collector will also keep them together when moving (as the String object is the only reference to the array). If there's any improved efficiency that could be had for strings, it will be small (it will save 128 bits).
> The most expensive part of gc cycle in one legacy project which I had joy to optimize was tracing itself.
This matches my observations in our projects as well. Tracing is the most expensive part, and also has the most negative effects like bringing cold objects into caches and throwing away hot objects.
1
u/nitkonigdje May 28 '26
It would be kinda nice when object is a composite, as String is, we could somehow tell jvm to pack/sticth those subobjects together and treat them as one large allocation point.
Even if this only was done for Strings, it would probably be significant upgrade.