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