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

[Coleen Phillimore]

On 3/23/15, 5:27 AM, Severin Gehwolf wrote:
> On Fri, 2015-03-20 at 16:34 -0400, Coleen Phillimore wrote:
>> 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()) {
> I'm not sure I understand the question. Could you elaborate? What's
> "platform support in jtreg" exactly?

Sorry, that question was meant for the jtreg experts.  There may be 
better way to exclude certain tests.

How do you run hotspot/test/runtime/CompressedOops tests since 
CompressedOops isn't supported with Zero?

thanks,
Coleen

>
> FWIW, I'm not aware of any specific Zero support in jtreg itself.
>
> Cheers,
> Severin
>
>> 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
>>>>>
>>>
>
>