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] | |
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] |