United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4933273 Flattened alias type for [KlassPtr + offset] must be consistent
JDK-4933273 : Flattened alias type for [KlassPtr + offset] must be consistent

Details
Type:
Bug
Submit Date:
2003-10-06
Status:
Resolved
Updated Date:
2003-10-23
Project Name:
JDK
Resolved Date:
2003-10-23
Component:
hotspot
OS:
generic
Sub-Component:
compiler
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0
Fixed Versions:
5.0 (beta)

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

Description
When flattening the alias type for [KlassPtr + Offset], the code in 
flatten_alias_type() is incorrect and leads to assertion failures at:

memnode.cpp line 87:
    assert(adr_type() == NULL || adr_type()->empty() || phase->C->must_alias(adr_type(), alias_idx), "adr_type must match alias idx");


compile.cpp line 908, Compile::flatten_alias_type( const TypePtr *tj )
  ...
  // 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
    if (offset == Type::OffsetBot || offset < sizeof(Klass))
      tj = tk = TypeKlassPtr::make( ptr, TypeKlassPtr::OBJECT->klass(), offset );


The problem occurs when a the memory input to an AddP changes from inexact to 
exact and the input to TypeKlassPtr::make changes from TypePtr::NotNull to 
TypePtr::Constant.  This implies that two memory accesses can be incorrectly 
scheduled when one starts out being a Constant and the other does not.

Problem has been observed on AMD64/LIN64 when running 200_check, but is in 
machine independent code that is run on all platforms.


                                    

Comments
SUGGESTED FIX

compile.cpp line 908:

  // 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
    if (offset == Type::OffsetBot || offset < sizeof(Klass))
!     tj = tk = TypeKlassPtr::make( ptr, TypeKlassPtr::OBJECT->klass(), offset );
-----
  // 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
+   // Flatten all of these to TypePtr::Constant.  Otherwise 
+   // the array of alias types could contain two entries with 
+   // different alias indices, one imprecise and one precise, 
+   // even though the memory accesses are to the same location.
    if (offset == Type::OffsetBot || offset < sizeof(Klass))
!     tj = tk = TypeKlassPtr::make( TypePtr::Constant, TypeKlassPtr::OBJECT->klass(), offset );

                                     
2004-06-11
EVALUATION

Since the type for a memory access can change from non-constant to constant, flatten_alias_type() must flatten both TypeKlassPtr accesses equally.
-----
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together