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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
