Request for reviews (S): 6836054: java/util/Arrays/ fails on solaris-sparc with IllegalArgumentException

Vladimir Kozlov Vladimir.Kozlov at Sun.COM
Fri May 8 14:49:56 PDT 2009

We don't know statically during a method compilation the actual type
because it is loaded dynamically for reflaction allocation.
Escape Analysis requires to know the type statically to pass it to debug info:

   const Type *t = local->bottom_type();
   // Is it a safepoint scalar object node?
   if (local->is_SafePointScalarObject()) {
     SafePointScalarObjectNode* spobj = local->as_SafePointScalarObject();

     ObjectValue* sv = Compile::sv_for_node_id(objs, spobj->_idx);
     if (sv == NULL) {
       ciKlass* cik = t->is_oopptr()->klass();
       assert(cik->is_instance_klass() ||
              cik->is_array_klass(), "Not supported allocation.");
       sv = new ObjectValue(spobj->_idx,
                            new ConstantOopWriteValue(cik->encoding()));


Tom Rodriguez wrote:
> I have to admit I don't really follow this logic in the code.  How is it 
> that we can allocate something but not know it's actual type?  Isn't 
> that required to emit the allocation in the first place?
> tom
> On May 7, 2009, at 8:29 PM, Vladimir Kozlov wrote:
>> Fixed 6836054: java/util/Arrays/ fails on 
>> solaris-sparc with IllegalArgumentException
>> Problem:
>> Escape Analysis requires that allocations should have
>> exact type (by using CheckCastPP node) for restoring
>> objects during deoptimization. But reflection allocation
>> set type to j.l.Object assuming that caller will cast
>> to exact type. In the failing case there is no cast
>> to array type so debug info contains incorrect type
>> (j.l.Object) for scalar replaced array allocation.
>> It causes the Exception after deoptimization.
>> Solution:
>> Do not mark an allocation as scalar replaceable if
>> it does not have exact type.
>> Reviewed by:
>> Fix verified (y/n): y, bugs case
>> Other testing:

More information about the hotspot-compiler-dev mailing list