JDK-4933273 : Flattened alias type for [KlassPtr + offset] must be consistent
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-10-06
  • Updated: 2003-10-23
  • Resolved: 2003-10-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_08Fixed
Related Reports
Relates :  
JDK-4907522 - VM asserts on solsparc running specjbb2000
Relates :  
JDK-4802814 - assertion failure: adr_type must match alias idx in PIT testing.
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
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger-beta INTEGRATED IN: tiger-beta
14-06-2004
EVALUATION Since the type for a memory access can change from non-constant to constant, flatten_alias_type() must flatten both TypeKlassPtr accesses equally. -----
11-06-2004
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 );
11-06-2004