RFR(S) 8235220: ClhsdbScanOops.java fails with sun.jvm.hotspot.types.WrongTypeException

[Chris Plummer]

Ping! Can I get one more review please.

thanks,

Chris

On 4/9/20 10:21 PM, Ioi Lam wrote:
> Hi Chris,
>
> Thanks for fixing this. It looks good to me.
>
> - Ioi
>
> On 4/9/20 9:44 PM, Chris Plummer wrote:
>> Hello,
>>
>> Please review the following:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235220
>> http://cr.openjdk.java.net/~cjplummer/8235220/webrev.00
>>
>> First off, thanks to Ioi for tracking this one down and proposing the 
>> fix.
>>
>> The test is executing the clhsdb "scanoops" command, which scans the 
>> specified heap address range looking for objects of the specified 
>> type (or all objects if no type is specified). The test determines 
>> the address range by first using clhsdb "universe" to get the start 
>> and end of the eden space. scanoops then iterates over this entire 
>> range, calling RobustOopDeterminator.oopLooksValid() on each oop as 
>> it iterates over the range. The problem is eventually you'll end up 
>> past the initialized part of the heap. That causes 
>> VirtualBaseConstructor.findDynamicTypeForAddress() to return null, 
>> resulting in throwing a WrongTypeException. 
>> RobustOopDeterminator.oopLooksValid() should catch this exception and 
>> return false when it happens.
>>
>> The CR mentions a few different failure modes. This only fixes the 
>> WrongTypeException failure. The NullPointerException is only on OSX 
>> and I believe is the same as JDK-8241158 [1], which happens when 
>> dumping the heap, so it seems probable that it is also turning up 
>> when scanning part of the heap. I think this bug was preventing us 
>> from ever seeing the WrongTypeException on OSX. Then there also 
>> JDK-8230731 [2] on Windows, which seems to prevent ever seeing the 
>> WrongTypeException on Windows.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8241158
>> [2] https://bugs.openjdk.java.net/browse/JDK-8230731
>>
>> thanks,
>>
>> Chris
>