RFR: 8212879: Make JVMTI TagMap table concurrent [v5]
Coleen Phillimore
coleenp at openjdk.java.net
Thu Nov 5 12:30:00 UTC 2020
On Wed, 4 Nov 2020 08:56:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:
>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Code review comments from Kim and Albert.
>
> src/hotspot/share/prims/jvmtiTagMapTable.hpp line 36:
>
>> 34: class JvmtiTagMapEntryClosure;
>> 35:
>> 36: class JvmtiTagMapEntry : public HashtableEntry<WeakHandle, mtServiceability> {
>
> By using utilities/hashtable this buys into having to use HashtableEntry, which includes the _hash member, even though that value is trivially computed from the key (since we're using address-based hashing here). This costs an additional 8 bytes (_LP64) per entry (a 25% increase) compared to the old JvmtiTagHashmapEntry. (I think it doesn't currently make a difference on !_LP64 because of poorly chosen layout in the old code, but fixing that would make the difference 33%).
>
> It seems like it should not have been hard to replace the oop _object member in the old code with a WeakHandle while otherwise maintaining the Entry interface, allowing much of the rest of the code to remain the same or similar and not incurring this additional space cost.
Yes, there is 64/32 bits extra per hashtable entry with the standard hashtable implementation. It wouldn't have been hard to replace the oop object, but using shared code was a goal of this change.
-------------
PR: https://git.openjdk.java.net/jdk/pull/967
More information about the serviceability-dev
mailing list