RFR (M): 7157365: jruby/bench.bench_timeout crashes with JVM internal error (original) (raw)

John Rose john.r.rose at oracle.com
Thu Jun 14 15:42:57 PDT 2012

Reviewed.

— John

P.S. One comment: This code in memnode.cpp obscured the root of your problem:

case T_OBJECT: #ifdef _LP64 if (adr->bottom_type()->is_ptr_to_narrowoop()) { Node* load = gvn.transform(new (C, 3) LoadNNode(ctl, mem, adr, adr_type, rt->make_narrowoop())); return new (C, 2) DecodeNNode(load, load->bottom_type()->make_ptr()); } else #endif

There should be a separate case T_NARROWOOP here, instead of overloading T_OBJECT and secretly distinguishing the adr-type. The LoadNode::make factory should have a 1-1 relation between BasicType and LoadNode subtype. Most uses of T_OBJECT mean "object value in a register".

The choice of using T_NARROWOOP should (probably) be moved higher up the call chain, to make it more clear which kind of oop we are referring to. I would consider putting the decision in Parse::do_get_xxx and parallel uses of GraphKit::make_load.

It seems to me, in this moment, that those few occurrences of T_OBJECT which map to memory references to compressed oops should be made explicitly T_NARROWOOP. The alternative (non-compressed in-memory values) could be tagged T_ADDRESS (or maybe T_WIDEOOP) for explicitness, or T_OBJECT could continue to be a full word (as ArrayElementSize appears to promise).

Would you mind filing a separate bug for cleaning this up? The #ifdef should go away too, of course. (If there is already an #ifdef removal bug, this could be added as a comment.)

On Jun 14, 2012, at 2:38 PM, Christian Thalinger wrote:

http://cr.openjdk.java.net/~twisti/7157365

7157365: jruby/bench.benchtimeout crashes with JVM internal error Reviewed-by: The problem manifests itself as an assert in escape analysis code: assert((ptnodeadr(adr->idx) == NULL || ptnodeadr(adr->idx)->asField()->isoop())) failed: sanity The out-of-line code for invokedynamic instructions loads the CallSite object from the constant pool cache. Since the constant pool cache contains data other than oops we return the type as byte[] and load the oop as raw pointer. Escape analysis notices this misbehavior and bails out. The best possible fix for now is to define the constant pool cache base pointer as an oop array and load a raw pointer from there. Note that this is more of a temporary fix since the perm-gen removal will fix this problem in a more correct fashion. src/share/vm/memory/universe.hpp src/share/vm/opto/callGenerator.cpp src/share/vm/opto/chaitin.cpp src/share/vm/opto/type.cpp

More information about the hotspot-compiler-dev mailing list