RFR (S): 7195816: NPG: Crash in c1_ValueType - ShouldNotReachHere

Roland Westrelin roland.westrelin at oracle.com
Mon Sep 10 06:45:42 PDT 2012


Thanks for taking a look at this.

> Thank you for fixing c1.  We didn't realize there was this much left out.

I took the opportunity to clean things up a bit. The minimal fix for this particular problem could maybe have been smaller but I think the code is better that way and could help catch problems in the future.

>  In c1_LIRAssembler_x86.cpp,  this is sort of confusing.   I would prefer a separate case for C1_METADATA, because it would use UseCompressedKlassPointers rather than UseCompressedOops so even without the ifdef, part of this case doesn't make sense.    Do you have fixes for this in your UseCompressedKlassPointer changes?

A metadata ptr manipulated by c1 can be either a klass ptr or a method ptr. When the code is emitted in c1_LIRAssembler_*.cpp, we know something is a metadata ptr but the extra bit of information that tells whether it's a method or klass ptr is lost. The code below is the single place where the fact that we don't know whether the ptr is a klass or a method could be a problem: a metadata ptr is written to memory but on 64 bit with compressed klass ptrs it could be either a 32 bit store or a 64 bit store. Anyway, this code path is only taken on 32 bit because the code that C1 generates and the 32 bit x86 C calling convention are such that the only case where a metadata ptr is written to memory is to write it to the stack to pass as an argument to a dtrace runtime call.

This code doesn't change with the UseCompressedKlassPointer changes.

In short it's a corner case that only happens on x86/32 bit.

> Why isn't there the same sort of change from c1_LIRAssembler_sparc.cpp?

All arguments to dtrace runtime calls are passed in registers so we won't try to write one of them to memory.

Roland.


More information about the hotspot-compiler-dev mailing list