User-defined deserialization [Was: On constant folding of final field loads]
aph at redhat.com
Thu Jul 23 10:02:19 UTC 2015
On 21/07/15 00:05, John Rose wrote:
> We have enough bits in the object header to encode frozen-ness.
> This is an opposite property: slushiness-of-finals. We could
> require that the newInstance operation used by deserialization would
> create slushy objects. (The normal new/<init> sequence doesn't need
> this.) Ideally, we would want the deserializer to issue an explicit
> "publish" operation, which would clear the slushy flag. JITs would
> consult that flag to gate final-folding. Reflection (and other
> users of Unsafe) would consult the flag and throw a fail-fast error
> if it failed. There would have to be some way to limit the time an
> object is in the slushy state, ideally by enforcing an error on
> deserializers who neglect to publish (or discard) a slushy object.
> For example, we could require an annotation on deserialization
> methods, as we do today on caller-sensitive methods.
> That's the sort of thing I would prefer to see, to remove
> indeterminate behavior.
Which reminds me: an issue has arisen regarding Unsafe and
user-defined deserialization. Some middleware uses non-Java-standard
serialization protocols which require some sort of backdoor mechanism
for creating objects which have no zero-arg constructor. Unafe is
used to do this, as is ReflectionFactory, but both are internal APIs.
I don't think there's anything inherently unreasonable about people
wanting to write their own serialization protocols, but having to call
internal APIs is fragile. I suppose we would like to tell the runtime
that an object is no longer slushy, but there is no "official"
interface for serializers to create objects in the first place.
More information about the hotspot-compiler-dev