larval value type and carrier object
john.r.rose at oracle.com
Mon Jan 28 22:20:47 UTC 2019
On Jan 26, 2019, at 5:32 AM, forax at univ-mlv.fr wrote:
> Just for the record, i was talking about the global carrier object, the one in between several match + extract call, the one returned by the call to invokedynamic, not the ones which are a box the return values of a call to a de-constructor/extractor.
Yes, that's what I was talking about: The "scratch buffer" contains
all the state unpacked by the deconstructor. Its type is completely
unimportant, except that it is agreed upon by the deconstructor
and its component extraction methods. The client code just sees
java.lang.Object for the buffer, and never knows what's there.
As I said, it could be an old-school Object. If the deconstructed
components are all stable with respect to the original object
(which is the case with immutables) then the scratch buffer can
be (or need not be) an alias to the same (immutable) object.
(Isn't it unsafe to make it an Object array, since that is mutable?
Probably not, since the buffer itself is temporary, and the client
code walks away with whichever components it picks out of it.
There are odd exploits possible if the buffer escapes from the
JVM locals, however.)
My main point here is that the scratch buffer for the deconstructed
components can be any old type, including very old types like
Object. Formally, it is an unbounded existential type.
> For the result of a call to a deconstructor, any value records is Ok, obviously, any records will work but this will create perf issues.
More information about the valhalla-dev