JVM verifier and Unsafe.allocateInstance in LambdaForm

[-]

Hello John and Valhalla community,
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.

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.

Truly curious,
Chen Liang

[1]: https://cr.openjdk.org/~jrose/values/larval-values.html
[2]: https://github.com/openjdk/jdk/pull/13853
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230828/3221494a/attachment.htm>