Lost perf between 8u40 and 9 hs-comp

[Vladimir Ivanov]

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