IdentityHashMap & natStackTrace

[Rutger Ovidius]

Thursday, November 25, 2004, 10:24:43 PM, you wrote:

RM> Rutger Ovidius wrote:

>> These two issues seem to be a burden on the heap.  I can drop ~400k of
>> ram by doubling the size of this instead of using "old.length << 1 +
>> 2" during each table expansion.

RM> Good catch!

Tracking down large heap memory blocks leads to interesting findings. :)

RM> This was introduced almost two years ago in a merge from
RM> Classpath:

RM> http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/util/IdentityHashMap.java.diff?r1=1.8&r2=1.9&only_with_tag=MAIN

RM> You should either file a bug or submit a patch fixing
RM> this issue.

I'll include a patch that reverts the shifts to the multiplication use
of the patch you mention above if anyone wants to use it. Also, the
second setting of threshold had an extra "/ 2" which didn't seem right
so I got rid of it (the threshold would be too small).

>> This implementation fills the array with emptyslot (Arrays.fill),
>> which uses a whole bunch of memory. Can't a guard be used on lookups
>> instead of actually filling this in (checking equality with
>> emptyslot)?

RM> Can you elaborate on that?  Note that a NULL can't be used and
RM> "emptyslot" is a reference to the same sentinel Object.

It is the use of Arrays.fill that I questioned. Iterating through so
many items and filling them when they might never be used seemed (in
theory) like a waste, but, maybe it isn't such a big deal.

Regards,
Rutger Ovidius

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ihm.diff
Type: application/octet-stream
Size: 2072 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/java/attachments/20041126/e952ed68/attachment.obj>