Can immutable value objects be pulled?

[Chen Liang]

Hi Evemose,
Pooling of value object is already there; it is a VM implementation detail not visible to users, unlike the identity of String objects. In fact, according to JEP 401, JVM is also free to duplicate value objects for faster access (locality). If you declare your record value, it will be eligible for pooling like any value object.

For String pooling, I believe JVM currently uses a hash table, but it is somewhat less efficient if the table grows too large; String.intern, the public API for String pooling, is slower than putting String into your own HashMap to deduplicate. However, some String objects are known to be pooled, such as the literal constant strings in Java source code or class file string constants and method names. I have seen user string pooling in handling of configuration for remapping Java class files, where many descriptors and class names duplicate. (On a side note, annotation string values are not pooled, and this causes significant memory usage in some applications with duplicate string annotation values)

Another object that's pooled is MethodType, and its pooling is completed mandated by Java code. Its pooling via a ReferencedKeySet is more valuable than String pooling, as in addition to reducing allocations, MethodType also caches Invokers, which are relevant utilities for working with MethodHandles of the type.

Chen
________________________________
From: valhalla-dev <valhalla-dev-retn at openjdk.org> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Saturday, June 8, 2024 3:16 PM
To: valhalla-dev at openjdk.org <valhalla-dev at openjdk.org>
Subject: Can immutable value objects be pulled?

Hi! I am writing to express some thoughts that have been crossing my mind pretty often recently. So basically, what I am wondering is can value objects be pooled, just like Strings are pooled now?

My thoughts originated from the question of pooling value records and records in general Value objects seem like ideal candidates to be pooled: they don't have identity, so there are no things like two different value objects with the same state but not "completely" equal. Things like optionals tend to often repeat values, as well as some things that records are used for such as DTOs and other plain data carriers.

The thing that kind of doubts me is that usual records also are a good candidate for pooling, but, AFAIK, they aren't for some reason, so I am wondering maybe this idea has been considered previously but discarded for some reason like inacceptable performance overhead associated with pooling mechanism.

But still, widening mechanism that used for String pooling currently I`m not familiar with exact implementation of String pooling and I suspect it somehow tied to inlining string literals and that's why it doesn't work for any other way to create string, so it seems like adapting it to any constructor will require significant change in pooling mechanism, but it seems like it potentially could save up ton of memory. I'm not sure about the performance side of this though.

This letter is more of a question as I am not familiar with string pooling internals at all, but it seems like a natural thing to me.So, has this been considered?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240609/71046d37/attachment.htm>