RFR(M) 8243500: SA: Incorrect BCI and Line Number with jstack if the top frame is in the interpreter (BSD and Windows)

[Chris Plummer]

Yeah, it took a while for me to come up with a reasonable test. It 
possibly could use some tuning. I first required it match 5 out of 5 
lines, and do so in 30 seconds. Then I realized that a fixed time wasn't 
a good idea, nor matching every line. It failed frequently, mostly on 
slower machines but sometimes even on fast machines due to bad luck. So 
I figured out how to get the target to terminate when the main test was 
done so a timer wasn't needed, and also relaxed the requirement for 
matching every line so the test wouldn't need to run as long, eventually 
settling on 5 out of 10 lines instead of 5 out of 5. A port without the 
8231634 fix will at most match 2 lines (start and end of loop) although 
I think I only ever saw it match the line at the start of the loop.

thanks,

Chris

On 4/28/20 1:02 PM, serguei.spitsyn at oracle.com wrote:
> Hi Chris,
>
> LGTM++
> The test is interesting.
>
> Thanks,
> Serguei
>
>
>
> On 4/28/20 12:16, Chris Plummer wrote:
>> Thanks Alex!
>>
>> Can I get one more review please?
>>
>> Chris
>>
>> On 4/27/20 6:52 PM, Alex Menkov wrote:
>>> Hi Chris,
>>>
>>> The fix looks good.
>>>
>>> --alex
>>>
>>> On 04/27/2020 12:17, Chris Plummer wrote:
>>>> Ping! Please help review if you can.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 4/24/20 12:44 AM, Chris Plummer wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8243500
>>>>> http://cr.openjdk.java.net/~cjplummer/8243500/webrev.00/index.html
>>>>>
>>>>> A couple years ago JDK-8214226 fixed an issue on Linux-x64 with SA 
>>>>> stack dumps not properly displaying the correct line number for 
>>>>> the topmost frame if it was interpreted. The issue was that SA was 
>>>>> always relying on frame->bcp when in fact the BCP is kept in R13, 
>>>>> and only flushed to frame->bcp when needed as a scratch register. 
>>>>> So this means that SA was in most cases grabbing a stale value 
>>>>> from frame->bcp.
>>>>>
>>>>> The fix for JDK-8214226 was mostly made in X86Frame.java to 
>>>>> support using the BCP register for the topmost frame instead using 
>>>>> frame->bcp. This fix actually had a bug in it that was causing the 
>>>>> "illegal bci" failures we've been seeing. There is already a 
>>>>> separate webrev and RFR out for that:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8231634
>>>>> http://cr.openjdk.java.net/~cjplummer/8231634/webrev.00/index.html
>>>>>
>>>>> What this RFR addresses is the fact that part of the fix for 
>>>>> JDK-8214226 was in LinuxAMD64JavaThreadPDAccess.java, but the same 
>>>>> changes were never made to WindowsAMD64JavaThreadPDAccess.java or 
>>>>> BsdAMD64JavaThreadPDAccess.java. This fix addresses those two 
>>>>> ports. Here's the CR and changeset for reference:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8214226
>>>>> http://hg.openjdk.java.net/jdk/jdk/rev/9a73a4e4011f
>>>>>
>>>>> The changes for the fix are pretty trivial. The more complicated 
>>>>> part is the test I added that will reproduce the issue 100% of the 
>>>>> time on platforms where SA does not properly check the BCP 
>>>>> register. For this reason I've used @requires to limit running 
>>>>> this test on just those platforms I know have the support in 
>>>>> place. The test has pretty good comments on how it works, so I 
>>>>> won't go into details here.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>
>>
>