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

Reply via email to