Request for reviews (XS): 7048030: is_scavengable changes causing compiler to embed more constants
Vladimir Kozlov
vladimir.kozlov at oracle.com
Tue May 24 20:26:46 PDT 2011
Thank you, John
Vladimir
John Rose wrote:
> Yes; thanks. You can count me as a reviewer. -- John
>
> On May 24, 2011, at 6:36 PM, Vladimir Kozlov wrote:
>
>> Tom Rodriguez wrote:
>>> On May 24, 2011, at 6:00 PM, John Rose wrote:
>>>> 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.
>> make_from_constant() is called with require_constant == true for invokedynamic CallSites and it calls can_be_constant() which will return true for ScavengeRootsInCode >= 1. So it should continue to work for 292.
>>
>> Vladimir
>>
>>>> But, I think this will continue to work if ScavengeRootsInCode is not zero. Do you agree?
>>> It should restore the logic to how it used to work prior to 7041789.
>>> http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/raw-diff/2aa9ddbb9e60/src/share/vm/gc_interface/collectedHeap.hpp
>>> @@ -284,11 +291,7 @@ class CollectedHeap : public CHeapObj {
>>> // An object is scavengable if its location may move during a scavenge.
>>> // (A scavenge is a GC which is not a full GC.)
>>> - // Currently, this just means it is not perm (and not null).
>>> - // This could change if we rethink what's in perm-gen.
>>> - bool is_scavengable(const void *p) const {
>>> - return !is_in_permanent_or_null(p);
>>> - }
>>> + virtual bool is_scavengable(const void *p) = 0;
>>> 292 ignores should_be_constant anyway.
>>> tom
>>>> -- 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