Re: fun with Java

>
> I hear you and agree that some extra overhead is to be expected since
> the spamprobe/java parser is running inside of hotspot.  There is bound
> to be some overhead from hotspot itself and that's fine.  What bothered
> me was:
> 1. that the RSS varied tremendously during the run
> 2. that the program would not run at all with a max heap of 256 megs

That is definately outrageous ...


>
>
>> See #2
>>
>> * GC on exit.
>> The main theoretical advantage (IMHO) to a GC environment vs say C or
>> C++ is that it doesnt free ... so you have no time calling free()/delete
>> However, the tests you run, if your running end-to-end (start, run,
>> exit) in fact DO call free at the end (or final GC ...)
>
> According to Boehm (only GC expert whose papers I have read) a flurry of
> frees on exit is one of the maladies that GC fixes.  If the process is
> shutting down then there is zero reason to do any freeing.  The whole
> process address space is about to be deallocated by the OS anyway.  I
> have some C/C++ programs that deliberately don't call free on exit
> unless I am running a leak test inside of valgrind.

Even if no "frees" are called, in java it does have to "finalize" every 
object on exit.  You cant just exit.
Atleast that is my understanding.  You cant avoid it like you can in C and 
C++ by avoiding "free" or "delete".
However, I suspect the majority of overhead wasnt that though ...

Another curiosity ... exactly how similar were the C++ and java codes ? This 
bites both ways ...
If they were identical, then a 2.5x overhead for java is understandable, 
however I too have heard it shouldnt happen (that modern java bytecode 
execution are suppose to be optimized so that it 'should' perform similarly,
but I have a hard time believing).

The other side of the question is that you may be able to perform the same 
"task" in java by using higher level constructs ... that are typically 
annoying to do in C++.   I suspect you did not do this for spamprobe ... 
that in fact the source was very similar.  For many types of things, 
probably spamprobe being one of them, you may not be *able* to gain any 
advantage using higher level constructs ... its largely an IO and arithmetic 
loop ...
But for some kinds of problems ... the ease of using more high level classes 
can lead to entirely different algorithms that solve the same problem ... 
and *can* (but not necessarily) lead to better performance.
I was just at a conference in Atlanta where such a strategy was benchmarked. 
In this case it was both java, but they compared a SAX XML parser with a 
"XML Bean" parser to perform the same task ... and were able to get the much 
higher level API ("XML Beans") to perform 2x - 3x faster then what one would 
'naturally' assume would be the faster, lower level API (SAX).





>
>
> What stunned me was how poorly the hotspot GC seemed to fare compared to
> the Boehm GC.  Here we had a program that could in theory run in 2 MB of
> active memory but needed almost 20 with the Boehm GC and hundreds with
> the hotspot VM.  Ouch.
BIG ouch.   I can rationalize the 20MB ... just the core java VM and basic 
classes can eat that ...
but not hundreds.   Thats just plain weird.






-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click