Idea how to implement VT/VO compatibility in JVM

[Palo Marton]

(See this thread:
http://mail.openjdk.java.net/pipermail/valhalla-dev/2015-January/000710.html
)

Main idea is to move information about using VT from method descriptors to
metadata.

E.g. for method

double distanceTo(point p);

the corresponding method descriptor will “pretend” that the actual
parameter is boxed object reference, like (LPoint;)D. But in metadata
(could be eg. parameter annotation in class that declares the method) it
will indicate that this is actually value type. This way the method
descriptor for VT and VO will be the same and VO based code should actually
be able to call VT based method. (note: this “VT erasure” should not be
done for arguments like ‘point p[]’ as array of VT is very different from
array of VO).

Of course such change will require a bit different implementation of VT in
JVM.

One big issue with such implementation is that when mixing VT/VO code,
situation may arise where one method overrides other method and they have
different VT flags for their arguments/result, which means that they have
also different calling convention for JITed code. The same may happen when
implementing interface. This may be solved by allocating another slot in
vftable for that function and filling original slot with some small bridge
code that will handle needed boxing/unboxing and call method from the right
vftable slot. So in case of mixed VT/VO code there may be multiple slots
for one method (=method descriptor) in vftable. Big change, I know…

Other issue is that if we move info about VT from method descriptor to
metadata, we should do the same also for bytecode of method. So bytecode
will manipulate VT values using normal reference instructions (aload,
astore, …). This also means that JVM interpreter will use only boxed VT
values. It is a performance penalty for interpreter, but may be this is not
so important as most code will be JITed. JIT compiler can utilize
information from metadata to do more aggressive stack/register allocation
(no escape analyses is needed for VT values) and better argument passing
and result returning.

There are many other issues with this. For some of them I see solution, but
there are probably many “devils in details” that I can not see.


Question: Have you considered such approach to VT? It basically means that
VT is implemented as value object for which JIT can do more aggressive
optimizations thanks to metadata included in places where it was used as VT
in the source code.