I have a heap dump with an internal cache held in a ConcurrentHashMap. This map has 6648 entries, but has contended access so the size is recored as follows
- map
- baseCount = 836
- counterCells
If I navigate to this object in the heap dump and Use Java Collections -> Hash Entries then I get the expected 6648 entries. If I do an OQL query like SELECT ${h}[0:-1] FROM OBJECTS 951406 h (where 951406 is the object id of my concurrent hash map) then I only get 836 entries. I notice that KnownCollectionInfo.java has two cases for concurrent hash maps
// FIXME This is only approximate and just works for some
// small maps.
new CollectionExtractionInfo("java.util.concurrent.ConcurrentHashMap", JdkVersion.of(JAVA18, IBM18, JAVA19, IBM19, JAVA_11), new HashMapCollectionExtractor("baseCount", "table", "key", "val")), // //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ //$NON-NLS-4$ //$NON-NLS-5$
new CollectionExtractionInfo("java.util.concurrent.ConcurrentHashMap", JdkVersion.except(JAVA18, IBM18, JAVA19, IBM19, JAVA_11), new ConcurrentHashMapCollectionExtractor("segments", "key", "value")), // //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$ //$NON-NLS-4$So, I'm not entirely surprised it isn't working, but it would be nice to either get an error or have it be consistent.
I have a heap dump with an internal cache held in a
ConcurrentHashMap. This map has 6648 entries, but has contended access so the size is recored as followsIf I navigate to this object in the heap dump and Use Java Collections -> Hash Entries then I get the expected 6648 entries. If I do an OQL query like
SELECT ${h}[0:-1] FROM OBJECTS 951406 h(where 951406 is the object id of my concurrent hash map) then I only get 836 entries. I notice thatKnownCollectionInfo.javahas two cases for concurrent hash mapsSo, I'm not entirely surprised it isn't working, but it would be nice to either get an error or have it be consistent.