This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IdentityHashMap & natStackTrace


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

Attachment: ihm.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]