<div dir="ltr">Hello John and Valhalla community,<br>Reading the recent John Rose post "Larval Values" [1], which is about how verifier's special rules on new-dup-<init> sequence can be applied to value classes, I recall that in the code generated by DirectMethodHandle's lambda forms, another sequence is used to initialize objects: Unsafe.allocateInstance -> astore -> aload -> <init>. And in my patch [2] where I seek to migrate serialization constructor implemented with special-ruled classes (new-dup-<init>, but <init> a superclass, allowed per special VM rules), this MH allocateInstance sequence apparently allows me to call <init> of an unrelated class on the allocated object in my experiments, such as calling Character's <init> on a String, though it has no visible effect on the String object.<br><br>Are these behaviors of allocateInstance intended? Does the verifier treat allocateInstance with a special rule? Since I am not familiar with JVM internals written in C++ (being a pure Java developer), I hope someone familiar with these matter, such as John who both led JSR 292 and now is an important engineer in Valhalla, can help explain what exactly is going on with Unsafe::allocateInstance in LambdaForms, and how this pattern will evolve with the introduction of value types in Valhalla.<br><br>Truly curious,<br>Chen Liang<br><br>[1]: <a href="https://cr.openjdk.org/~jrose/values/larval-values.html" target="_blank">https://cr.openjdk.org/~jrose/values/larval-values.html</a><br>[2]: <a href="https://github.com/openjdk/jdk/pull/13853" target="_blank">https://github.com/openjdk/jdk/pull/13853</a><br></div>