[External] : Re: Can immutable value objects be pulled?

[Chen Liang]

Hi Olex,
In Valhalla, immutability will be easy: value is immutability. And the depth of immutability is easy, too: you have immutability until you reach a reference pointer in the tree. And yes, when Valhalla is out, the famous -128 to 127 Integer cache range will be gone; all Integer will == each other if their values pass ==.

String and MethodType "pooling" are reduction of instances, which is more of a feature on the Java code side and only matters for reference objects. Their storage devices, arrays, are not simple values, thus we seek to pool them. They are unlikely to be affected by Valhalla, and VM can't duplicate or eliminate them as it treats value objects.

> I feel like creating a new instance of sume numeric type, even if it is done by duplicating an existing one, is still a pretty significant overhead compared to just returning pointer to existing one, given that object is immutable, and, therefore, can have as many immutable refs as possible.

Your concerns are very valid, that reference pointers are much smaller than a majority of objects' full layout. In these cases, JVM has the full freedom to decide if a value object is small enough to be allocated directly (for small values like Float16, UnsignedInt, both are smaller than a 64-bit pointer), or if allocating a pointer to a heap value object (either existing or newly allocated) is better (for larger ones, maybe like 4*4 square matrix used in graphic transformations). These choices are often made according to platform attributes, so leaving them to the VM instead of the Java code (which should "build once, run everywhere") is the correct choice.

P.S. I believe your question is valuable; therefore, I have forwarded to valhalla-dev, so people with similar questions can find their answers.

Chen Liang
________________________________
From: Olexandr Rotan <rotanolexandr842 at gmail.com>
Sent: Sunday, June 9, 2024 6:22 AM
To: Chen Liang <chen.l.liang at oracle.com>
Subject: [External] : Re: Can immutable value objects be pulled?

Hi Chen!

Thanks for the answer. I am writing to you privately to not pollute valhalla list traffic. I have a few questions about the VM implementation of this pooling. As you said, VM is free to duplicate objects. What I am wondering is: there are types that are not shallowly immutable by declaration, but are immutable effectively. As I understand, boxed types and optional fall under this umbrella as they are not records, but still effectively immutable. Does VM just have a list of built-in types that are "effectively immutable" and knows that it can pool its instances instead of duplication, or It decides whether type is mutable or not based on some features (like all fields are final, type is final etc.)?

I feel like creating a new instance of sume numeric type, even if it is done by duplicating an existing one, is still a pretty significant overhead compared to just returning pointer to existing one, given that object is immutable, and, therefore, can have as many immutable refs as possible.

Thanks for your time,
Regards

On Sun, Jun 9, 2024 at 11:47 AM Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
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<mailto:valhalla-dev-retn at openjdk.org>> on behalf of Olexandr Rotan <rotanolexandr842 at gmail.com<mailto:rotanolexandr842 at gmail.com>>
Sent: Saturday, June 8, 2024 3:16 PM
To: valhalla-dev at openjdk.org<mailto:valhalla-dev at openjdk.org> <valhalla-dev at openjdk.org<mailto: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/ae9ba02c/attachment.htm>