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