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

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: isscavengable changes causing compiler to embed more constants This is the cause of 7047300 problem to appear. The fix for 7041789 corrected the meaning of isscavengable to really mean what it says. Unfortunately there were some places that were really using it as a proxy for !isperm. In particular in ciObject::canbeconstant and shouldbeconstant we will now embed constants that we didn't used as long as they are in tenured. The code should be changed from !isscavengable to isperm. Verified with failing test from 7047300.

More information about the hotspot-compiler-dev mailing list