User-defined deserialization [Was: On constant folding of final field loads] (original) (raw)

Andrew Haley 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/ 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.

Andrew.

More information about the hotspot-compiler-dev mailing list