RFR (xs) 8037138: x86: problem with JVMTI breakpoint

[Coleen Phillimore]

On 8/18/16 9:44 AM, Daniel D. Daugherty wrote:
> On 8/17/16 3:36 PM, Coleen Phillimore wrote:
>> Summary: do aload(0) after rewriting aload bytecodes to fast version 
>> for frequent pairs.
>>
>> This is more of a cleanup since RewriteFrequentPairs is turned off 
>> for breakpoint debugging, because if frequent pairs of bytecodes are 
>> rewritten, you can't set a breakpoint on the second bci of a pair 
>> because it's not executed with this optimization.
>>
>> Now all the platforms are the same as ppc for this.
>>
>> Tested with jprt since aload(0) in the interpreter is executed a many 
>> times.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8037138.01/webrev
>
> src/cpu/aarch64/vm/templateTable_aarch64.cpp
>     No comments.
>
> src/cpu/sparc/vm/templateTable_sparc.cpp
>     No comments.
>
> src/cpu/x86/vm/templateTable_x86.cpp
>     No comments.
>
> Thumbs up.
>
> Just to be clear... this bad oop problem (and the loss of the
> tos value) only happens when -XX:+RewriteFrequentPairs is
> specified on the command line... Do I have this right?

It's also tied to capabilities.  When you update the capability

   if (avail.can_generate_breakpoint_events) {
     RewriteFrequentPairs = false;
   }

It is turned off.  From what I can tell when we update the jvmti 
capabilities it's turned on but that could be after the interpreter is 
generated, but RewriteFrequentPairs is on by default.

So this seems wrong too.  :(

Coleen


>
>
> Dan
>
>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8037138
>>
>>
>> See bug for how this came up on the openjdk thread.
>>
>> Thanks,
>> Coleen
>>
>