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

[Coleen Phillimore]

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
>