RFR (M) 8026977: NPG: Remove ConstantPool::lock
Coleen Phillimore
coleen.phillimore at oracle.com
Thu Jun 12 15:57:57 UTC 2014
On 6/12/14, 11:43 AM, Christian Thalinger wrote:
> +Mutex* ConstantPool::lock() {
> + // Use the lock from the metaspace in the rare instance we need to lock the entries
> + // in this cpool or its associated cache. Only used for setting invokedynamic cpCache
> + // entry.
> + return pool_holder()->class_loader_data()->metaspace_lock();
> +}
>
> I’d rather see this method removed completely and use the metaspace
> lock explicitly in ConstantPoolCacheEntry::set_method_handle_common.
> Otherwise it's confusing.
Ok, I can change that.
Coleen
>
> On Jun 11, 2014, at 2:13 PM, Coleen Phillimore
> <coleen.phillimore at oracle.com <mailto:coleen.phillimore at oracle.com>>
> wrote:
>
>> Summary: Write klass and resolved_references constant pool fields
>> lock free.
>>
>> The constant pool values that can change were already read lock free,
>> through the cpSlot type (lsb set for Symbol vs. Klass) for
>> JVM_CONSTANT_{Unresolved}Class. With Permgen elimination, the other
>> values that can change were moved to the resolved_references array,
>> which is initialized to null. Non-null is the resolved value. With
>> a couple uses of CAS, we can eliminate the need for the constant pool
>> lock for the constant pool changes. Error handling also changes the
>> tag but saving the resolution exception was done under the
>> SystemDictionary_lock, so only the tag change needs a CAS.
>>
>> The only remaining use for the constant pool lock is updating the
>> cpCache for invokedynamic. There are 4 fields that need to be
>> consistent. These now use the metaspace lock associated with the
>> class loader that owns the constant pool, which is only held briefly.
>> I ran some performance tests written by Sergey Kuksenko which show
>> no regression.
>>
>> Other testing - ran refworkload on linux x64 with no significant
>> results. Passed JPRT (runThese), vm.quick.testlist, jck8 tests,
>> hotspot jtreg tests and jdk java/lang/invoke jtreg tests.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8026977/
>> <http://cr.openjdk.java.net/%7Ecoleenp/8026977/>
>> bug link https://bugs.openjdk.java.net/browse/JDK-8026977
>>
>> Thanks,
>> Coleen
>>
>>
>
More information about the hotspot-dev
mailing list