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

[Bob Vandette]

> On Feb 7, 2019, at 8:36 PM, dean.long at oracle.com wrote:
> 
> 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?


The only difference with the unsafe call is the guarantee that we’re not looking up
a dead CodeBlob.  This should never be the case in an exception situation.

Bob.


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