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

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Jun 14 17:45:04 PDT 2012


OK then.

Thanks,
Vladimir

Christian Thalinger wrote:
> On Jun 14, 2012, at 3:53 PM, Vladimir Kozlov wrote:
> 
>> Christian,
>>
>> Can you move duplicated code in callGenerator into separate method?
> 
> Actually the code in PredictedDynamicCallGenerator is (currently) not used.  Only the path for the selectAlternative idiom.  I'm thinking about removing the code when we integrate our new implementation and resurrect it when we need it.
> 
> -- Chris
> 
>> Thanks,
>> Vladimir
>>
>> Christian Thalinger wrote:
>>> http://cr.openjdk.java.net/~twisti/7157365
>>> 7157365: jruby/bench.bench_timeout crashes with JVM internal error
>>> Reviewed-by:
>>> The problem manifests itself as an assert in escape analysis code:
>>> assert((ptnode_adr(adr->_idx) == NULL || ptnode_adr(adr->_idx)->as_Field()->is_oop())) 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