On Wed, 4 Nov 2020 13:19:21 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:

>> 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.

So looking at the concurrent hashtable, the entries can be created without 
saving the hashcode.  I was going to use that at first but didn't want to 
cut/paste the boilerplate to do so and the jvmti tag map hashtable is always 
accessed with a lock.  This could be a future RFE if necessary and would also 
serve to eliminate another ad-hoc hashtable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/967

Reply via email to