Re: possible bug in TreeMap.sucessor implementation

2002-12-21 Thread Dalibor Topic

--- Brian Jones <[EMAIL PROTECTED]> wrote:

> Since nil is supposed to have children that are also
> nil it appears
> that at some point nil.right was assiged a value.  

would it be possible to make nil an "ImmutableNode",
so that such assignments are caught and greeted with
an Error? that should make your life easier next time
you have to debug a similar case.

best regards,

dalibor topic

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath



Re: possible bug in TreeMap.sucessor implementation

2002-12-21 Thread Eric Blake
Dalibor Topic wrote:

Since nil is supposed to have children that are also
nil it appears
that at some point nil.right was assiged a value.  


would it be possible to make nil an "ImmutableNode",
so that such assignments are caught and greeted with
an Error? that should make your life easier next time
you have to debug a similar case.


For debugging, yes.  For efficiency, no.  Creating an ImmutableNode 
would require reworking the entire TreeMap class to use method calls, 
rather than field assignments, for manipulating nodes.  Adding 
polymorphic calls is an additional layer of indirection, and will make 
the overall implementation slower.

I still haven't had a good look into the bug, but I have finally got the 
time to spend on it now, and have reproduced it.  So look for a fix by 
the end of the day (I hope).

--
This signature intentionally left boring.

Eric Blake [EMAIL PROTECTED]
  BYU student, free software programmer




___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath


java.util.zip speedup

2002-12-21 Thread Artur Biesiadowski
I have taken java version of java.util.zip from CVS and done few 
optimalizations.

I have zipped entire classpath CVS tree (5MB packed). My test program 
goes through all entries and uncompress each to memory array (same every 
time, preallocated). I have tested validity of changed by adding write 
function to recreate all files - it works ok (after fixing one existing 
bug - current version in CVS has problems with unpacking files with 0 
length).

I have measured time taken for processing using java3d high res timer, 
counting only part from opening to closing zip file - no pre and post 
computation, no jvm startup. I have started program many many times, to 
make sure everything is in memory cache. I have measured both first and 
average of 9 next iterations, but percentage speedup is similar. I have 
used sun jre 1.4.1 for testing.

Classpath CVS version needs 3150ms. My optimized version manages to do 
it in 2125ms (results vary +-3ms in each case). I think this is quite 
reasonable speedup. But real fun comes with memory. Classpath CVS 
allocates around 130MB of garbage during processing, my version  fits in 
 1MB (most of it being zip entries/names). I suppose that most of time 
difference comes from less gc work (but I have also made few 
optimalizations for reading entries from disk).

I'm quite shocked to see how fast sun gc is - even if all difference 
comes from memory, we are talking about allocating and collecting 130MB 
in 1 second - this IS a lot. I suppose that with bigger/more complicated 
heap, gc time, and thus difference, would increase considerably. Anyway, 
on less advanced jvms, difference in amount of garbage should make 
greater impact[1].

Now, the ugly part. Few of optimalizations (algorithm and IO-related) 
are free. But biggest part (memory savings) require some caching. This 
means that around 35kb is allocated first time zip subsystem is used and 
will never get freed. There is also a need for quite close look at 
inflater sharing versus security.

My question - is 35kb of memory taken 'forever' an acceptable price for 
a lot less garbage on runtime ?

Artur

[1] - On sun jvm with interpreter, difference is still around 1 second - 
but this time between 26s with classpath CVS versus 25s with my 
version... most time here is probably spend in actual decoding



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath