JDK-6633953 : type2aelembytes[T_ADDRESS] should be 8 bytes in 64 bit VM
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2007-11-26
  • Updated: 2011-04-20
  • Resolved: 2011-04-20
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.
JDK 6 Other
6u14Fixed hs12Fixed
Description
In globalDefinitions.cpp from the first day T_ADDRESS size is defined as 'int' size:

int type2aelembytes[T_CONFLICT+1] = {
...
  T_OBJECT_aelem_bytes,   // T_OBJECT   = 12,
  T_ARRAY_aelem_bytes,    // T_ARRAY    = 13,
  0,                      // T_VOID     = 14,
  T_INT_aelem_bytes,      // T_ADDRESS  = 15,   
  0                       // T_CONFLICT = 16,
};

I think, this is because T_OBJECT_aelem_bytes was also 4 when it was created.
T_OBJECT and T_ARRAY sizes were fixed when VM was changed to support 64 bits oops.

The incorrect T_ADDRESS size in 64-bits VM produces whong size of StoreP nodes
attached to Initialize:

  virtual int memory_size() const { return type2aelembytes[memory_type()]; }

As result EA can't find stores through Initialize node.
The current code which use InitializeNode::find_captured_store() may also be broken. 
I think, it works now because LoadP and StoreP has the same T_ADDRESS type.

Comments
SUGGESTED FIX Fix T_ADDRESS size in type2aelembytes: int type2aelembytes[T_CONFLICT+1] = { ... T_OBJECT_aelem_bytes, // T_OBJECT = 12, T_ARRAY_aelem_bytes, // T_ARRAY = 13, 0, // T_VOID = 14, T_OBJECT_aelem_bytes, // T_ADDRESS = 15,
26-11-2007

EVALUATION See Description.
26-11-2007