Request for reviews (XS): 7048030: is_scavengable changes causing compiler to embed more constants

John Rose john.r.rose at oracle.com
Tue May 24 18:00:18 PDT 2011


If this affects the processing of 292 data, there may be significant performance regressions.  The key uses of embedded non-perms are invokedynamic CallSites, which requires TypeOopPtr::make_from_constant to succeed for user-provided CallSite objects.

But, I think this will continue to work if ScavengeRootsInCode is not zero.  Do you agree?

-- John

P.S.  FTR, some of history behind is_scavengable and is_perm is in this discussion, relating to 6863023:
  http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2009-September/001261.html

On May 24, 2011, at 5:19 PM, Vladimir Kozlov wrote:

> http://cr.openjdk.java.net/~kvn/7048030/webrev
> 
> Fixed 7048030: is_scavengable changes causing compiler to embed more constants
> 
> This is the cause of 7047300 problem to appear.  The fix for 7041789 corrected the meaning of is_scavengable to really mean what it says.  Unfortunately there were some places that were really using it as a proxy for !is_perm.  In particular in ciObject::can_be_constant and should_be_constant we will now embed constants that we didn't used as long as they are in tenured.  The code should be changed from !is_scavengable to is_perm.
> 
> Verified with failing test from 7047300.



More information about the hotspot-compiler-dev mailing list