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 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 re-run the interpreter
definition of MHI.profileBoolean using Action_reinterpret.
That would update the state, wouldn't it? Then the compiler would
recompile (after a little time) and see the updated state.
Just setting reexecute=true isn't enough - MHI.profileBoolean is located
earlier in bytecode, but only last instruction will be reexecuted.
Here's an excerpt from GWT bytecode:
...
invokevirtual MH.invokeBasic:(...)I
invokestatic MHI.profileBoolean:(Z[I)Z <== profiling
istore n
...
iload n
iconst_1
iand
ifeq m <== trap happens here
...
In general, there could be other actions between ifeq &
MHI.profileBoolean, so it's not possible to restore state and reexecute
the code starting from MHI.profileBoolean.
Am I missing something?
Best regards,
Vladimir Ivanov
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
