
<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br></div><div><br></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Glavo" <zjx001202@gmail.com><br><b>To: </b>"valhalla-dev" <valhalla-dev@openjdk.java.net><br><b>Sent: </b>Monday, November 28, 2022 11:10:18 AM<br><b>Subject: </b>Replace the primitive class with a more general null safety?<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr">After I read the JEP and related documents of Project Valhalla, I doubted the necessity of the existence of primitive classes.<br><br>It is impossible to migrate from identity class to primitive class, which will break binary compatibility.<br>This is a big obstacle for third-party libraries to support Valhalla.<br></div></blockquote><div><br></div><div>[...]<br data-mce-bogus="1"></div><div><br></div><div>yes, it's something we are working on.<br></div><div>Obviously, it will never be fully backward compatible because the default value of a value class and a primitive class are different (null and zeroes respectively).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><br>At the same time, in order to support non null types, the universal generics draft also greatly undermines compatibility.</div></blockquote><div><br></div><div>??<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><br>Although the value class is more compatible, it may not be inlined when it is a field or array member.<br>Therefore, sometimes value objects are repeatedly boxed, which may have worse performance than non value classes.</div></blockquote><div><br></div><div>The VM goes into great length to avoid that, by re-using the box.</div><div>If the box escapes the inlining horizon, yes, you will see the allocation, but it's the same issue with a lot of the other optimizations today, outside of the inline horizon the JIT is almost blind.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br>Providing both value class and primitive class may also make it more difficult for users to choose.</div></blockquote><div><br></div><div>Yes, we tried really hard, for several years in fact, to have only one kind of value classes.<br></div><div>But the physics of those two is different enough that trying to unify them or disguise one as the other is a worst than exposing that choice to the user.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><br>I don't like the current draft very much. In particular, I am very dissatisfied with the huge cost of providing null safety only for primitive types.</div></blockquote><div><br></div><div>Java null safety is a separate discussion ...<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>[...]<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><div dir="ltr"><br><br>If we do, we no longer need the primitive class. It is enough to mark the value class as non null.<br>The problem that prevents us from migrating to the primitive class no longer exists, because we don't need the primitive class and Q type anymore.</div></blockquote><div><br></div><div>I think you are mixing the syntax and the semantics here.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>The is an early access build that you can test, so you will get a better idea of how things work<br data-mce-bogus="1"></div><div>  <a href="https://jdk.java.net/valhalla/">https://jdk.java.net/valhalla/</a><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>By default, you only have value class [1] and if you want primitive class [2] you have to enable it at compile time and runtime.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>We know that primitive classes as describe in the JEP [2], do not fully integrate with the rest of the ecosystem that's a work in progress.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>regards,<br data-mce-bogus="1"></div><div>RÃ©mi<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>[1] <a href="https://openjdk.org/jeps/8277163">https://openjdk.org/jeps/8277163</a><br data-mce-bogus="1"></div><div>[2] <a href="https://openjdk.org/jeps/401">https://openjdk.org/jeps/401</a><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div></div></div></body></html>