Re: fun with Java

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

David A. Lee wrote:
> There are a few issues that can tweek the interpretation of your results.

Thanks David.  I'm going to respond to your points below.  I'm not 
arguing with you, just offering my own insights from the years I've 
spent writing production systems in both C++ and Java.


> * Memory usage
> 17MB is not unheardof simply to load the JVM ... What I would be 
> interested is Delta VM .... that is,
> load the JVM, run a very simple program, snapshot the VM used,  then run 
> your spamprobe tests within the JVM and see where it goes.

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


> Even still, the concepts of garbage collection are such that unless you 
> really force otherwise it will allocate more memory instead of reclaim.
> This can be a "feature" ... the java JVM is not optimizing for minimum 
> memory used.  Likely your never hitting the GC at all until exit ...

True.  The GC can be tuned in a large number of ways but a 10x swing in 
RSS is pretty out of control.  Note that the native spamprobe/java 
parser was also using GC (Boehm conservative GC) and its RSS varied very 
little thoughout the run.  My understanding is that Boehm GC is tuned 
for growing the heap only when necessary.  That definitely showed here.


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


> This is why App Servers are used (among many other reasons).   You prime 
> the pump, run the app, and DO NOT include the exit/GC time as part of 
> your calculations.    It would be interesting to simulate this.  i.e. 
> make a java main that runs some dummy stuff to 'prime the pump' then set 
> your timer to 0, run the spamprobe, then report the time.   THEN exit.

Agreed but this test was deliberately designed to minimize the effects 
of startup overhead.  I parsed the same BIG file around seven times. 
That gave the VM plenty of chance to run post load and to run with 
native JIT'd code on the successive passes over the file.


 > Anyway .. this is the logic I learned when taking a C# class last year
 > .. it makes some kind of perverted sense in the right usage pattern

I'm a big fan of GC.  It lets the machine do work during runtime that 
takes a lot of up front design to implement by hand.  It's also a lot 
less error prone.  OO design really shines when you have a GC to handle 
the memory management since you don't have to worry about explicit 
passage of control over the lifetime of returned objects.

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.


> The usage pattern of a JVM starting/running/exiting for short operations 
> is not a usage pattern that java excells at ... even if ran fast in 
> between ...

Agreed.


> I *have seen* real java programs running enterprise transaction systems, 
> running 500+ transactions/sec doing real work, faster and more scalable 
> then equivilent C programs ... but they take 30+ seconds to get up and 
> going ... I wouldnt be supprised if the next N+1 version of Windows has 
> a CLR in the OS or something to "hide" the startup overhead so that the 
> one-shot usage model becomes efficient.

As a guy who really enjoys writing software in Java I think the biggest 
advantage it offers is that you can implement much more ambitious 
projects than you can in C++ with a given level of effort.  The built in 
threading is also a huge win as all libraries have to be written with 
threading in mind and either be thread safe or document that they are 
not.  Threading is an afterthought in C++ libraries.

I was just disappointed to see that Java hasn't caught up as much as I'd 
thought it would have in the years it's been around.  Of course this is 
highly VM dependent too.  It might be that the Solaris or Windoze VMs 
would have done significantly better. I was also disappointed that even 
native compiled java (using GCJ) was much slower than its C++ equivalent.

Anyway this isn't a Java mailing list so I'll stop talking now.  I just 
posted my measurements in a spamprobe context in case others would find 
the data interesting.  I'm certainly not bashing Java since I really 
like the language!

I'll continue to enjoy developing software in both C++ and Java, but 
spamprobe in only C++. :-)

All the best,
++Brian

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2425)

iQEVAwUBQ3yiPjxRyEoJfXIFAQhgkAgAoekm6V6nx7ACwsuUMBPUTtFnVabQ0nvR
RZXmKfl1Bzgklt4+u2DNLecr9JhMhMoVhC5YVpoiyBZu5SBP/iz+7aXtmGBZm5dl
CwCTTkZoYqFE/DOka+7utFN8xrCJVNTmbfVKaaCvS6G/4o/kCuNbFBEP28Ne/v7L
ykc6NCKQGye9km/rmUgolTSXgNUhVoGMamvv8wU+3k/dxEx9RXFp3YDtpXQMIEIS
qpmnmRGkPipuLhV0KV4xJqzwsfFj91dGtlLawfH5Gyv8q3sRI9Tz/mRI3Bi5/vMa
KYOHbts/tS/1PyMYYJcmDR1GDSrPAF//wTaE0dagoWDppv/Ztqw5UA==
=Tz5q
-----END PGP SIGNATURE-----


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