peter-lawrey
commented
10 years ago In SharedHashMap it doesn't need to do this and I will put this Pull Request on hold until that class is finished because I believe we can avoid the whole issue.
On 12 February 2014 16:02, Jaromir Satanek notifications@github.com wrote:
Current implementation of HugeHashMap handles CharSequence type specifically. It converts it into a string whenever it needs to use CharSequence as a key for standard java.util.HashMap (this is correct because for instance StringBuilder does not override equals and hashCode methods and needs to be converted into a string). Consequently the HugeHashMap creates a new string with every put (line 252, current version of HugeHashMap).
The proposed modification introduces a concept of reusable vs immutable key. For all operations on java.util.HashMap except put, we use reusable key, for put we MUST create an immutable copy of the reusable key.
3 additional comments:
- The API is not as nice as in the original solution but it helps to avoid creating unnecessary objects on the heap and makes sure that reusable key objects are not used as keys for java.util.HashMap.put operation.
- The proposed modifiation requires that the Key type implements BytesMarshallable interface. This might be too restrictive in some cases (?).
- I am not sure that all the changes will be accepted but in general I
think it is a step in the right direction.
You can merge this Pull Request by running
git pull https://github.com/jaromirs/HugeCollections master
Or view, comment on, or merge it at:
https://github.com/OpenHFT/HugeCollections/pull/7 Commit Summary
- HugeHashMap modified so that every entry that cannot be stored into offheap memory and is stored into standard HashMap does not use recycled key object.
- Cosmetic change in testPutLong unit test
- Specific handling of CharSequence completely removed.
File Changes
- M collections/src/main/java/net/openhft/collections/HugeHashMap.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-0(84)
- A collections/src/main/java/net/openhft/collections/HugeMapKey.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-1(23)
- A collections/src/test/java/net/openhft/collections/CharSequenceKey.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-2(100)
- M collections/src/test/java/net/openhft/collections/HugeHashMapTest.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-3(47)
- A collections/src/test/java/net/openhft/collections/IntKey.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-4(44)
- M collections/src/test/java/net/openhft/collections/SegmentTest.javahttps://github.com/OpenHFT/HugeCollections/pull/7/files#diff-5(104)
Patch Links:
- https://github.com/OpenHFT/HugeCollections/pull/7.patch
- https://github.com/OpenHFT/HugeCollections/pull/7.diff
Reply to this email directly or view it on GitHubhttps://github.com/OpenHFT/HugeCollections/pull/7 .
jaromirs
Current implementation of HugeHashMap handles CharSequence type specifically. It converts it into a string whenever it needs to use CharSequence as a key for standard java.util.HashMap (this is correct because for instance StringBuilder does not override equals and hashCode methods and needs to be converted into a string). Consequently the HugeHashMap creates a new string with every put (line 252, current version of HugeHashMap).
The proposed modification introduces a concept of reusable vs immutable key. For all operations on java.util.HashMap except put, we use reusable key, for put we MUST create an immutable copy of the reusable key.
3 additional comments: