What can we improve in JSR292 for Java 9?

[Remi Forax]

On 03/04/2015 12:00 PM, Julien Ponge wrote:
> Hello,
>
> I echo Jochen's griefs on constructors. There are cases of dynamic subclassing or bytecode wizardry where one would like to make that call with invokedynamic, and being forced into doing so with an invokespecial to not break the verifier rules is a big problem.
>
> Other than that having some support for intrinsic invocation counters on GWT branches would probably be very helpful when creating polymorphic-inline caches.
>
> One invalidation or periodic invalidation we could use those metrics to reorder the GWT, and possibly prune old ones.

When I was at Oracle office after JFokus, we discuss about how to 
implement a kind of lightweight safepointing.
Charles need this to implement thread control in Ruby.
I have the same kind of requirement, I want to be able to trigger a GC 
of an off-heap data structure managed by a C library (the code of the 
library is not thread safe :( ) so basically I want to be able to stop 
all the thread of my language to do a coordinate change.

Technically it's not an invalidation because, the VM should not trash 
any code, just periodically enter in a code.
It can not be implemented with a volatile flag because like a VM 
safepoint the check has to be inserted in most of the loops and the 
slowdown is noticeable, it can not be implemented with a SwitchPoint 
because it will trigger a deoptimization.

The idea is to create another kind of MethodHandle that works like a 
SwitchPoint, but that let me switch it on and off several time.
The VM will also be allowed to cluster several of these user safe points 
into one.

The way to implement it in the VM is to do code patching using a non 
temporal move.to change the code that is executed and revert it back 
when necessary.

Rémi

>
> An open question that I have is that of facilitating the support of overloaded methods. It's typically something dynamically-typed languages struggle with, and doing it correctly *and* efficiently is not that pretty.
>
> - Julien
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev