code review round 1 for JDK-8028749 java -version crashes with 'fatal error: heap walk aborted with error 1'

[Staffan Larsen]

Looks good!

Thanks,
/Staffan


On 14 maj 2014, at 05:10, Ron Durbin <ron.durbin at oracle.com> wrote:

> Greetings,
> 
> This fix was revised after the initial round of code review.
> The code and the invite have been revised.
> 
> This fix resolves:
> 
> JDK-8028749 java -version crashes with
>            'fatal error: heap walk aborted with error 1'
> 
> Summary:
> When traversing the C Heap in the Windows OS  the heap lock must
> held. If HeapWalk() is called to walk the heap without holding the
> lock it can fail. If HeapLock() is called to lock the heap it can fail if
> heap checking like windows gflags.exe is enabled. Failure to check
> the return status of HeapLock() can result HeapWalk failing to
> traverse the heap.
> 
> The call to HeapLock() return status is now checked and if the status
> indicates a failure the heap checking is skipped.
> 
> You will find the webrev by following the URL below.
> 
> http://cr.openjdk.java.net/~rdurbin/JDK-8028749-webrev-cr1
> 
> 
>> -----Original Message-----
>> From: Ron Durbin
>> Sent: Friday, May 02, 2014 12:08 PM
>> To: hotspot-runtime-dev at openjdk.java.net
>> Cc: Ron Durbin
>> Subject: code review round 0 for JDK-8028749 java -version crashes with 'fatal error: heap
>> walk aborted with error 1'
>> 
>> Greetings,
>> 
>> This fix resolves:
>> 
>> JDK-8028749 java -version crashes with
>>           'fatal error: heap walk aborted with error 1'
>> 
>> Summary:
>> When the gflags are enabled it appears that Windows does not
>> support application heap checking. This fix disables part of the
>> JVM heap check based on the Windows HeapWalk() API when certain
>> gflags checks are enabled.
>> 
>> Testing:
>> These code changes have tested by completing a successful HotSpot build
>> with windows heap checks turned on and off.
>> The heap check manipulation was done via gflages.exe
>> with a reboot following each change before each test run.
>> 
>> The success criteria was a successfully completed build without
>> the java command crashing and leaving a mini dump.
>> This fix disables part of the JVM heap check based on the Windows
>> HeapWalk() API when certain gflags checks are enabled.
>> 
>> You will find the webrev by following the URL below.
>> 
>> http://cr.openjdk.java.net/~rdurbin/JDK-8028749-webrev/0-jdk9-hs-runtime/