RFR: 8218169 - [AOT] Segmentation fault when running java with AOTed Graal in -Xcomp mode on windows

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Feb 7 20:22:32 UTC 2019


hs-tier1 runs AOT tests (tier1_compiler_not_xcomp) on all x64 platforms.

Vladimir

On 2/7/19 9:53 AM, Bob Vandette wrote:
> Thanks, I’ll make the change.
> 
> Do you know which mach5 tier, if any, performs AOT testing on Windows?
> 
> Bob.
> 
> 
>> On Feb 7, 2019, at 12:31 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Hi Bob,
>>
>> Very nice fix. Can you use #if INCLUDE_AOT instead of _WIN64 based on your description?
>>
>> Thanks,
>> Vladimir
>>
>> On 2/7/19 7:15 AM, Bob Vandette wrote:
>>> Please review this fix for a SEGV occurring when AOT is used on Windows.
>>> PROBLEM:
>>> The problem is caused by the fact that we're getting an implicit exception from the .text
>>> segment of an AOT generated library but the generated code in the DLL does not have
>>> any structured exception sections or unwind tables. The normal hotspot CodeCache works
>>> around this limitation by registering the entire code cache with RtlAddFunctionTable. In order
>>> to do this for AOT generated code, a DynamicCodeData structure would need to be generated
>>> in the text segment of the AOT library.
>>> BUG:
>>> https://bugs.openjdk.java.net/browse/JDK-8218169
>>> WEBREV:
>>> http://cr.openjdk.java.net/~bobv/8218169
>>> SOLUTION:
>>> Rather than modify the AOT implementation to generate a Windows specific data structure that
>>> requires a jmp out of the DLL code and into Hotspots exception handler, I chose a simpler solution
>>> that installs a VectoredException handler. This VectoredException handler is only installed if AOT
>>> is enabled.
>>> This handler examines the pc of the exception. If this pc is determined to be in either the
>>> codeCache or in AOT generated code, we pass control to the existing exception handler otherwise
>>> we allow the system to continue searching for other exception handlers.
>>> There were problems in the past with the use of VEH but at that time we made exclusive use of
>>> VEH and did not use them in conjunction with SEH.  Since I am only passing control to our
>>> existing handler when the pc is from one of our code sections, other code in the system can
>>> continue to use SEH.
>>> For more details, please see the bug comments.
>>> Bob.
> 


More information about the hotspot-runtime-dev mailing list