RFR(S): 8026495: JVM Crashes when started with -XX:+DTraceMethodProbes on Solaris x86_64

Igor Veresov igor.veresov at oracle.com
Tue Oct 22 22:51:13 PDT 2013


Thanks, Chris!

On Oct 22, 2013, at 10:50 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:

> 
> On Oct 22, 2013, at 9:35 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
> 
>> 
>> On Oct 22, 2013, at 8:33 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:
>>> + #ifdef _LP64
>>> +   Register thread = r15_thread;
>>> + #else
>>>     __ get_thread(rsi);
>>> !   __ movptr(rax, Address(rsi, JavaThread::exception_oop_offset()));
>>>     __ movptr(Address(rsi, JavaThread::exception_oop_offset()), (intptr_t)NULL_WORD);
>>> !   __ movptr(Address(rsi, JavaThread::exception_pc_offset()), (intptr_t)NULL_WORD);
>>> !   Register thread = rsi;
>>> + #endif
>>> I'd prefer using LP64_ONLY and NOT_LP64 on one line.
>> 
>> There is get_thread() on 32bit, it's not going to be one line. But I agree it's better looking.
>> Review updated in-place.
>> 
>>> 
>>> src/share/vm/c1/c1_LIRGenerator.cpp:
>>>     if (x->pass_thread()) {
>>> !     signature->append(T_ADDRESS);
>>> !     signature->append(LP64_ONLY(T_LONG) NOT_LP64(T_INT));    // thread
>>>       args->append(getThreadPointer());
>>>     }
>>> Why can it not be T_ADDRESS?
>> 
>> It can, but getThreadPointer() returns either T_INT or T_LONG (probably historically) and I'd like it to be consistent.
>> Speaking of T_ADDRESS, this change also fixes the size of  the T_ADDRESS spill, which was always 4 bytes.
> 
> I see.  Makes sense then.  Looks good.
> 
>> 
>> igor
>> 
>> 
>>> 
>>> On Oct 22, 2013, at 8:18 PM, Igor Veresov <igor.veresov at oracle.com> wrote:
>>> 
>>>> A bunch of problems here, starting from use of wrong calling convention in LIR_Assembler::emit_unwind_handler() - it simply hasn't been ported to 64bit.
>>>> Also, there are a bunch of holes left in C1 to support T_METADATA. The relevant for this problem are the calling convention generation, and the register allocator support.
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8026495/
>>>> 
>>>> Testing: Java2Demo with -XX:+DTraceMethodProbes, JPRT run in progress
>>>> 
>>>> igor
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20131022/4b9f4277/attachment.html 


More information about the hotspot-compiler-dev mailing list