<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Olex,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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 ==.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> 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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
P.S. I believe your question is valuable; therefore, I have forwarded to valhalla-dev, so people with similar questions can find their answers.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Chen Liang</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Olexandr Rotan <rotanolexandr842@gmail.com><br>
<b>Sent:</b> Sunday, June 9, 2024 6:22 AM<br>
<b>To:</b> Chen Liang <chen.l.liang@oracle.com><br>
<b>Subject:</b> [External] : Re: Can immutable value objects be pulled?</font>
<div> </div>
</div>
<div>
<div dir="ltr">Hi Chen!<br>
<br>
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.)?<br>
<br>
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.<br>
<br>
Thanks for your time,<br>
Regards</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Sun, Jun 9, 2024 at 11:47 AM Chen Liang <<a href="mailto:chen.l.liang@oracle.com">chen.l.liang@oracle.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div class="x_msg7395757570196848879">
<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi Evemose,</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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)</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Chen</div>
<div id="x_m_7395757570196848879appendonsend"></div>
<hr style="display:inline-block; width:98%">
<div id="x_m_7395757570196848879divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> valhalla-dev <<a href="mailto:valhalla-dev-retn@openjdk.org" target="_blank">valhalla-dev-retn@openjdk.org</a>> on
behalf of Olexandr Rotan <<a href="mailto:rotanolexandr842@gmail.com" target="_blank">rotanolexandr842@gmail.com</a>><br>
<b>Sent:</b> Saturday, June 8, 2024 3:16 PM<br>
<b>To:</b> <a href="mailto:valhalla-dev@openjdk.org" target="_blank">valhalla-dev@openjdk.org</a> <<a href="mailto:valhalla-dev@openjdk.org" target="_blank">valhalla-dev@openjdk.org</a>><br>
<b>Subject:</b> Can immutable value objects be pulled?</font>
<div> </div>
</div>
<div>
<div dir="ltr">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?
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>