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

[Coleen Phillimore]

Severin,  Thank you for taking care of this.   I have one question for 
the greater project.

Is there platform support in jtreg so we don't need to change the Java code?

http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8075533/webrev.01/test/runtime/ErrorHandling/SafeFetchInErrorHandlingTest.java.udiff.html

+    if (!Platform.isDebugBuild() || Platform.isZero()) {


Thanks,
Coleen

On 3/20/15, 1:45 PM, Severin Gehwolf wrote:
> Hi Volker,
>
> Thanks for the review!
>
> 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.
> You are right. I did some digging in the hg history and it seems this
> implementation for Zero has been added with JDK-8022188 after
> JDK-8016697 introduced it.
>
>> The current implementation of SafeFetch on Zero can not provide this
>> functionality so in my eyes it is useless.
> I agree.
>
>> 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)
> Sounds good, I'll follow up with an updated webrev shortly.
>
>> The test changes are good.
> Cheers,
> Severin
>
>> 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
>>>
>
>