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

[Coleen Phillimore]

This looks good to me and I'll sponsor it.  Thanks for answering my 
other question.

Thanks,
Coleen

On 3/23/15, 10:56 AM, Volker Simonis wrote:
> 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
>>>>
>>
>>