RFR: 8075533: Zero JVM segfaults for -version after JDK-8074552

Volker Simonis volker.simonis at gmail.com
Mon Mar 23 14:56:05 UTC 2015


Hi Severin,

your change looks good now except one minor thing I forgot to mention
in my last mail. Can you please always update the copyright year in
all the files you edit to the current year. And I also noticed that
the test "test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java"
has somehow slipped trough without any copyright header at all. Could
you please also add a complete copyright header to that file.

Unfortunately you still need a sponsor from within Oracle because you
touch shared files :(

Thank you and best regards,
Volker


On Mon, Mar 23, 2015 at 2:02 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Volker,
>
> Updated webrev which does what you suggested:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.02/
>
> Thanks,
> Severin
>
> On Fri, 2015-03-20 at 16:17 +0100, Volker Simonis wrote:
>> Hi Severin,
>>
>> I can't understand how SafeFetch32 and SafeFetchN are supposed to work
>> at all in Zero. The whole point of having the SafeFetch routines is to
>> have a possibility of peeking at potentially illegal memory addresses.
>> The current implementation of SafeFetch on Zero can not provide this
>> functionality so in my eyes it is useless.
>>
>> I think we should do the following:
>>  - StubRoutines::SafeFetchN_stub() should just return 'null' on Zero
>> (this way the unmodified CanUseSafeFetchXX() routines would work for
>> Zero as well)
>>  - remove the implementations of  SafeFetchN and SafeFetch32 and set
>> StubRoutines::_safefetchN_entry and StubRoutines::_safefetch32_entry
>> to NULL in stubGenerator_zero.cpp (this will automatically make
>> StubRoutines::SafeFetchN_stub() return null on Zero)
>>  - the calls to test_safefetch32XX() should be guarded by
>> CanUseSafeFetchXX() (this woul avoid the Zero ifdefs in
>> stubRoutines.cpp)
>>
>> The test changes are good.
>>
>> Regards,
>> Volker
>>
>>
>> On Fri, Mar 20, 2015 at 12:57 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>> > Hi,
>> >
>> > Could somebody please review and sponsor this patch?
>> >
>> > The commit of JDK-8074552 broke the Zero port since it performs tests on
>> > JVM initialization if SafeFetch32 and SafeFetchN on invalid pointers
>> > (relying on a continuation scheme for safe fetch errors) work. Yet
>> > performing this test correctly requires support from the signal handler
>> > and access routines to ucontext_t which are missing for Zero.
>> >
>> > The intent of JDK-8074552 was to improve error reporting on SEGV's.
>> > Having this feature in Zero is less useful, since it's a C++ interpreter
>> > only environment.
>> >
>> > This patch disables the test and makes CanUseSafeFetch* functions return
>> > false unconditionally for Zero JVMs so as to not produce a recursive
>> > SEGV's during error reporting.
>> >
>> > I've also updated test SafeFetchInErrorHandlingTest.java so it's skipped
>> > for Zero.
>> >
>> > bug: https://bugs.openjdk.java.net/browse/JDK-8075533
>> > webrev:
>> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/
>> >
>> > Testing done: make bootcycle-images fails before this patch and passes
>> > after for a Zero JVM on x86_64.
>> >
>> > Thanks,
>> > Severin
>> >
>
>
>


More information about the hotspot-runtime-dev mailing list