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