At the VM language summit at JFokus 2015, we discussed having ways to get new
dynamic language functions into the JVM without having to resort to generating
a class wrapping their byte code. A class is currently the smallest possible
compilation unit for the JVM, and its installation carries
John,
So let's make hindsight work for us: Is there a way (either with or without
the split you suggest) to more firmly couple the update to the query?
Separating into two operations might be the cleanest way to go, but I think
it's safer to keep both halves together, as long as the slow
On Mar 3, 2015, at 8:23 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Suggestion: Instead of have the intrinsic expand to nothing, have it expand
to an uncommon trap (on the slow path), with the uncommon trap doing the
profile update operation (as currently coded).
Right now,
New could would mean adding a {MethodHandle, ConstantPoolData}
tuple to a particular callsite?s representation.
Now if we could add a item for the object reference used for the
comparison in the test part of a GWT we would have a structure which could
be used
in a PIC
Thanks for looking into it Vladimir...I'm standing by to test out anything!
- Charlie
On Tue, Mar 3, 2015 at 10:23 AM, Vladimir Ivanov
vladimir.x.iva...@oracle.com wrote:
John,
So let's make hindsight work for us: Is there a way (either with or
without the split you suggest) to more firmly
Right now, VM doesn't care about profiling logic at all. The intrinsic
is used only to inject profile data and all profiling happens in Java
code. Once MHI.profileBoolean is intrinsified (profile is injected),
no profiling actions are performed.
What I'm thinking is that an uncommon trap could
Ah, I see now.
You suggest to conditionally insert uncommon trap in MHI.profileBoolean
when a count == 0, right?
Won't we end up with 2 checks if VM can't fold them (e.g. some action in
between)?
Best regards,
Vladimir Ivanov
On 3/4/15 2:15 AM, Vladimir Ivanov wrote:
Right now, VM
