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

[Jonathan Gibbons]

Coleen,

There's new stuff coming up in jtreg that will allow jtreg to query VM 
properties, as provided by the VM and VM SQE teams.  But that has not 
started yet.

-- Jon


On 03/23/2015 07:51 AM, Coleen Phillimore wrote:
>
> 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
>>>>>>
>>>>
>>
>>
>