RFR (urgent, S): 8009836: nsk/regression/b4222717 fails with empty stack trace

Coleen Phillmore coleen.phillimore at oracle.com
Tue Mar 12 15:46:03 PDT 2013


On 3/12/2013 6:40 PM, Vladimir Kozlov wrote:
> Coleen,
>
> Each allocation in Metaspace (Method is Metadata) is zeroed by calling 
> Metablock::initialize() in Metaspace::allocate(). So why these fields 
> can have random numbers?

With my last checkin, I took out this zero initialization and changed it 
to 0xf1f1f1f1 in debug mode.
Coleen

>
> Thanks,
> Vladimir
>
> On 3/12/13 11:04 AM, Coleen Phillimore wrote:
>>
>> Thank you for the code review, Dan.
>>
>> On 03/12/2013 11:00 AM, Daniel D. Daugherty wrote:
>>> On 3/12/13 7:52 AM, Coleen Phillimore wrote:
>>>> Summary: zero bit fields missed in Method* and ConstMethod*
>>>>
>>>> Tested with JPRT and failed test.   The other tests didn't find this
>>>> omission.
>>>> This bug might be causing JPRT c1 tests to get SEGV with stack
>>>> overflows too on the hotspot-rt baseline.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8009836/
>>>> bug link at http://bugs.sun.com/view_bug.do?bug_id=8009836
>>>
>>> src/share/vm/oops/constMethod.cpp
>>>     No comments.
>>>
>>> src/share/vm/oops/method.cpp
>>>     No comments.
>>>
>>> Maybe I'm being dense, but I don't see the connection between
>>> these code changes and the failure mode we're seeing. Can you
>>> explain the connection between these changes and the missing
>>> stack traces?
>>>
>>
>> In javaClasses.cpp at line 1560, the method was marked as hidden
>> randomly on solaris sparc probably because of the endianness.
>>
>>      if (method->is_hidden()) {
>>        if (skip_hidden)  continue;
>>      }
>>      bt.push(method, bci, CHECK);
>>      total_count++;
>>
>>> I'm going to guess that the fields that were not explicitly
>>> zero were randomly non-zero on some of the Solaris SPARC configs
>>> and that caused some confusion.
>>
>> yes.  I have a feeling that setting flags dont_inline and force_inline
>> could also cause confusion but the confusion there was more subtle.
>>>
>>>
>>> How do we know whether all the fields have been properly
>>> initialized?
>>
>> I had some temporary code that checked for the pattern 0xf1 from p =
>> this to p< header_size() and manually checked the exceptions. We have a
>> lot of gaps in instanceKlass so I couldn't leave the debugging code in.
>> So I checked them manually, unfortunately.
>>
>> thanks,
>> Coleen
>>>
>>>
>>> Dan
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Coleen
>>>
>>



More information about the hotspot-runtime-dev mailing list