Trimming ArrayList and HashMap During GC Copy

[Kim Barrett]

> On Jan 23, 2023, at 12:44 PM, Nathan Reynolds <numeralnathan at gmail.com> wrote:
> 
> > 1. Such a change would have user observable differences in behaviour, which could introduce bugs in user code, due to the optimization.
> 
> How is this user observable?  The Object[] is buried inside an ArrayList or HashMap.  This idea is not touching other Object[]'s outside a collection.

This could severely affect performance. One might create an ArrayList and use
ArrayList.ensureCapacity before adding a large number of elements, to reduce
incremental resizing of the internal array. Then you propose the GC can come
along and stomp on your capacity setting.

One can use ArrayList.trimToSize to eliminate excess capacity.

HashMap performance depends on having excess capacity to reduce collisions.
The HashMap constructor has an argument that is a hint of the expected number
of entries.  If your HashMaps are overly sparse you can either use a smaller
initial hint or copy into a new "right-sized" map.

I don't know how the GC could possibly reduce a HashMap, since the positions
of entries depend on information that the GC doesn't have nor can compute.

> I suppose a performance impact from having to grow is somewhat observable.  This was noted in my original email.  However, growing is not functionally observable.

Not functionally observable != not important for users.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20230124/1f944354/signature-0003.asc>