Request for reviews (M): 6674600, 6259129 (last Escape Analysis changes for HS12)

[John Rose]

On Mar 17, 2008, at 1:38 PM, Vladimir Kozlov wrote:

> ---------------------------------------------------------------------- 
> ------ http://webrev.invokedynamic.info/kvn/6674600/index.html
> Fixed 6674600: (Escape Analysis) Optimize memory graph for  
> instance's fields
> Problem:
> To reallocate a scalarized object during a deoptimization we need
> to know the state (values) of object's non-static fields at a  
> safepoint.
> Solution:
> Use aggressive memory optimizations during Iterative GVN
> to obtain values assigned to instance's non-static fields.

--- LoadNode::Ideal
It's OK.  There's a big chunk copied from loopopts, which is scary on  
two counts:
It's from loopopts, and it is a modified cut-n-paste.  That part  
needs to be
refactored back into a single copy, but it can be a separate cleanup.

We need a generally applicable split-through-phi as its own piece of  
code.

Review is complete.

> ---------------------------------------------------------------------- 
> ------ http://webrev.invokedynamic.info/kvn/6259129/index.html
> Fixed 6259129: (Escape Analysis) scalar replacement for non- 
> escaping objects
> Problem:
> To reallocate a scalarized object during a deoptimization we need
> to know the state (values) of object's non-static fields at a  
> safepoint.
> Solution:
> Replace non-escaping allocations with SafePointScalarObjectNode
> for a scalar replacement during macro expansion of Allocate nodes.
> Do an additional memory search to obtain values assigned to instance's
> non-static fields. Disable scalar replacement if a field's value
> can't be found.
> ---------------------------------------------------------------------- 
> ------

--- PhaseMacroExpand::value_from_mem_phi
Another case of phi specialization.  I think this also needs to be
refactored as a generally-applicable standalone chunk of code.

The code repeats lots of local analysis in the Ideal and Identity  
methods
of memnodes.  It has to repeat rather than reuse because the inputs to
the analysis are not quite local; they involve search over memory  
chains.

As a future cleanup, we should either factor the local analyses
so as to take "pluggable" search routines to traverse memory
edges nonlocally, or rethink our memory edges so that they
do not require search, so that graph transformations are
again dependent on local information only.

The code is OK, reviewed.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20080320/984d5082/attachment.html