JDK-6715633 : when matching a memory node the adr_type should not change
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2008-06-17
  • Updated: 2010-04-03
  • Resolved: 2008-07-02
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 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Relates :  
Description
>> Tom Rodriguez wrote:
>>> Here's a side question:  when matching a memory node we should expect 
>>> that the adr_type doesn't change.  Is there an obvious place to put 
>>> an assert about that during matching?  It's complicated because of 
>>> matches with multiple nodes but it would be nice to catch these 
>>> problems immediately.
>
> Vladimir Kozlov wrote:
>> So you want to add an additional adr_type field to all memory mach nodes
>> during matching and then compare in assert the result of MachNode::adr_type()
>> and this field. Is is correct? I will file a bug to investigate it.
>
Tom Rodriguez wrote: 
> Actually that's a good idea too.  Regular memnodes do something like 
> that right now I think to check that the adr_type doesn't change over 
> time.  I was just thinking that we should verify that the adr_type of 
> the ideal node matches the adr_type of the machnode that is produced for 
> it at match time.  Basically the adr_type shouldn't change from the time 
> the ideal memory operation is constructed to the time we emit assembly 
> for it.  We'd have caught this pretty early if we had these checks in 
> place.

Comments
SUGGESTED FIX Added the debug field _mem_node to Matcher class and set it to a memory node which is consumed by a mach node. Use it to verify the adr_type of the mach node which should not change. This check found the listed type problems. Put opaque nodes on the macro nodes list to remove them during macro expansion phase and to execute igvn transformations on users.
20-06-2008

EVALUATION MachNode::get_base_and_disp() does not process correctly an addressing with a narrow oop LoadConN node (is_Con() == true). As result the adr_type() for such addresses is "BotPTR* + bot" which aliases with all stores. The mach node loadNKlass has wrong bottom_type() since its base class is not MachTypeNode (as for loadKlass) because we missed it in InstructForm::captures_bottom_type). DecodeN::value() and EncodeN::value() always return the type with which a node was created when it should return the type based on the type of the current input node (which could be different from an original input node).
20-06-2008