RFR (xs) 8075967: Zero interpreter asserts for SafeFetch<32, N> calls in ObjectMonitor

[Coleen Phillimore]

On 3/25/15, 8:21 PM, David Holmes wrote:
> On 26/03/2015 10:04 AM, Coleen Phillimore wrote:
>>
>> On 3/25/15, 7:59 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> Why generate stubs that can't be used and then add zero-specific logic
>>> to the shared CanUseSafeFetchN instead of not generating the stubs so
>>> that CanUseSafeFetchN will return false anyway ??
>>
>> Because there is platform independent code in objectMonitor.cpp that
>> uses SafeFetchX (both).  I'd rather not burden the caller of this with
>> testing CanUseSafeFetchX for each call.   This code existed before
>> SafeFetch was implemented, so I'm restoring previous behavior for Zero.
>
> Sorry Coleen I thought this was deal to with 8075533, I hadn't 
> realized 8075533 broke the objectMonitor code and this was a follow up.
>
> What a mess. :(

Yes, it is.  Is this a code Review?
thanks!
Coleen
>
> Thanks,
> David
>
>
>
>> We could file an RFE to either implement SafeFetch for Zero or rewrite
>> this objectMonitor code to not need SafeFetch.  I didn't want to do
>> either of these things with this patch.
>>
>> Coleen
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 26/03/2015 3:53 AM, Coleen Phillimore wrote:
>>>> Summary: Implement SafeFetchX unsafely and make CanUseSafeFetchX false
>>>> for Zero
>>>>
>>>> Also, this fixes a couple other minor issues.
>>>>
>>>> Ran jdk9 jck tests with one timeout.  hotspot/runtime jtreg tests 
>>>> don't
>>>> run because Zero doesn't support UseCompressedOops (not sure why) and
>>>> CDS (know why).
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8075967/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8075967
>>>>
>>>> Thanks,
>>>> Coleen
>>