RFR(M): 8027422: assert(_gvn.type(obj)->higher_equal(tjp)) failed: cast_up is no longer needed
Roland Westrelin
roland.westrelin at oracle.com
Tue Nov 19 11:45:19 PST 2013
Thanks for reviewing this, Vladimir.
On Nov 19, 2013, at 1:34 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> Next 2 places in type.cpp pass 'true' to meet() unconditionally:
>
> 1929 return TypeAry::make(_elem->meet(a->_elem, true),
>
> 3812 const TypeAry *tary = _ary->meet(tap->_ary, true)->is_ary();
>
> Should TypeAryPtr::remove_speculative() also clean _speculative in element's type?
You’re right. It probably should.
So I need to add a remove_speculative() method to TypeAry. Then the 2 places where true is passed to meet() for TypeAry don’t matter anymore because remove_speculative() is called from meet() and remove_speculative now has an effect on TypeAry, right?
> Could you make printing code with 'this_t' aligned again in Type::meet()?
Sure.
Roland.
>
> thanks,
> Vladimir
>
> On 11/18/13 1:15 PM, Roland Westrelin wrote:
>> The root of the problem is that during the null check when the type of obj is improved in GraphKit::cast_not_null():
>> const Type *t_not_null = t->join(TypePtr::NOTNULL, true);
>> The join with TypePtr::NOTNULL is not applied to the speculative part. In fact, no meet between a TypeOopPtr and a TypePtr modifies the speculative part. One way to fix it would be to apply the meet with a TypePtr to the speculative part as well as the standard part of the type which I tried: then we need to move the _speculative field up in TypePtr and modify all operations on TypePtr to operate on _speculative so that the type system remains symmetric.
>> In many places where we mix a TypePtr with a TypeOopPtr we actually don’t care about the speculative part. I changed the following operations on Type:
>> higher_equal()
>> meet()
>> join()
>> filter()
>> so that by default they don’t return a result that include the speculative part of the type. Where we need the speculative part of the type, we have to explicitly request it.
>>
>> I also fixed a problem with Type nodes with a _type of TypeNarrowOop that wouldn’t drop the speculative part of the type during Compile::remove_speculative_types().
>> I included small clean ups that Mikael suggested privately (dropped the duplicate check for res->isa_oopptr() in TypeOopPtr::meet, make remove_speculative not go through the exercise of creating a new type if speculative is NULL).
>>
>> http://cr.openjdk.java.net/~roland/8027422/webrev.00/
>>
>> Roland.
>>
More information about the hotspot-compiler-dev
mailing list