RFR: 8218169 - [AOT] Segmentation fault when running java with AOTed Graal in -Xcomp mode on windows
bob.vandette at oracle.com
Fri Feb 8 00:43:18 UTC 2019
> 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.
>> On 2/7/19 7:15 AM, Bob Vandette wrote:
>> Please review this fix for a SEGV occurring when AOT is used on Windows.
>> 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.
>> 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.
More information about the hotspot-compiler-dev