type oddity

[Tom Rodriguez]

On Nov 28, 2011, at 10:40 AM, Vladimir Kozlov wrote:

> This changes were made for next bug. Bug report has explanation.
> 
> 4933273: Flattened alias type for [KlassPtr + offset] must be consistent

The explanation in there all makes sense.  The original bug was that it was using the incoming ptr instead of picking a single PTR for the flattening.  Picking Constant instead of NotNull doesn't make any sense though since it results in a more precise type than is probably warranted.  Functionally I think it makes little difference unless we try to assume that because the type of the AddP was precise that we could read through a constant.  Anyway, thanks for the history pointer.  Dean sent me that too.

tom

> 
> Vladimir
> 
> Tom Rodriguez wrote:
>> While looking into a failure in the metadata repo I noticed this code in flatten_alias_type:
>>  // Klass pointers to object array klasses need some flattening                                                                                          const TypeKlassPtr *tk = tj->isa_klassptr();
>>  if( tk ) {
>>    // If we are referencing a field within a Klass, we need                                                                                                // to assume the worst case of an Object.  Both exact and                                                                                              // inexact types must flatten to the same alias class.                                                                                                  // Since the flattened result for a klass is defined to be                                                                                              // precisely java.lang.Object, use a constant ptr.                                                                                                      if ( offset == Type::OffsetBot || (offset >= 0 && (size_t)offset < sizeof(Klass)) ) {
>>      tj = tk = TypeKlassPtr::make(TypePtr::Constant,
>>                                   TypeKlassPtr::OBJECT->klass(),
>>                                   offset);
>>    }
>> It's followed by a couple checks for specific fields where the PTR is changes to NotNull for just those offsets.  It seems odd to me that Constant is used here since we're flattening a non constant type into a constant one for some fields but not for others.  We end up with a constant class for things like the java_mirror field which seems wrong:
>> precise klass java/lang/Object: 0x08142438:Constant:exact+64 *
>> For objArrayKlass we convert it back to NotNull.  The comment explaining why Constant is used doesn't really make sense either.  Anyone know why it's done this way?
>> tom