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