In a recent enhancement we added new APIs to construct LinkedHashMap, HashMap and WeakHashMap instances as part of

Since we missed adding tests for that change, I have been working on adding some basic tests for this change as part of The draft PR is here

It's in draft state because it has uncovered an aspect of this change that we might have to address or document for these new APIs. Specifically, the tests I added now have a test which does the equivalent of:

// numMappings = 2147483647
var w = WeakHashMap.newWeakHashMap(Integer.MAX_VALUE);

Similar tests have been added for HashMap and LinkedHashMap too, but for the sake of this discussion, I'll focus on WeakHashMap. Running this code/test runs into:

test NewWeakHashMap.testNewWeakHashMapNonNegative(2147483647): failure
java.lang.OutOfMemoryError: Java heap space
    at java.base/java.util.WeakHashMap.newTable(
    at java.base/java.util.WeakHashMap.<init>(
    at java.base/java.util.WeakHashMap.<init>(
    at java.base/java.util.WeakHashMap.newWeakHashMap(
    at NewWeakHashMap.testNewWeakHashMapNonNegative(

This exception happens with only WeakHashMap. LinkedHashMap and HashMap don't show this behaviour. It appears that WeakHashMap eagerly creates an large array (of length 1073741824 in this case) in the newTable method which gets called by its constructor.

This raises a few questions about these new APIs - these APIs take an integer and the document allows positive values. So the current Integer.MAX_VALUE in theory is a valid integer value for this API. Should these APIs document what might happen when such a large numMapping is passed to it? Should that documentation be different for different classes (as seen the HashMap and LinkedHashMap behave differently as compared to WeakHashMap)? Should this "numMappings" be considered a hard value? In other words, the current documentation of this new API states:

"Creates a new, empty WeakHashMap suitable for the expected number of mappings
and its initial capacity is generally large enough so that the expected number
of mappings can be added without resizing the map."

The documentation doesn't seem to guarantee that the resizing won't occur. So in cases like these where the numMappings is a very large value, should the implementation(s) have logic which doesn't trigger this OOM error?


Reply via email to