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

[dean.long at oracle.com]

On 2/7/19 4:43 PM, Bob Vandette wrote:
>> On Feb 7, 2019, at 7:23 PM, dean.long at oracle.com wrote:
>>
>> With this fix, can we retire os::register_code_area()?
> We could if we enabled it unconditionally but I’d prefer to
> get some experience with this
> change isolated to AOT for a while.

OK.  The change looks good, except for one concern.  Should we use
find_blob_unsafe() inside the exception handler?

dl

> Bob
>
>> dl
>>
>>> 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.
>>>
>>>
>>>
>>>