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

[Ekaterina Pavlova]

I think hs-tier1 is not enough to verify this particular issue because the issue was not discovered by tier1 tests.
Bob, in addition to standard testing please follow mach5 instructions provided in the bug report to test on windows.

thanks,
-katya


On 2/7/19 12:22 PM, Vladimir Kozlov wrote:
> 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.
>>