[MUD-Dev] Brief point about Java memory management

[ceo at grexengine.com]

On Mon, Jun 03, 2002 at 03:29:55PM -0500, David B. Held wrote:
> From: <ceo at grexengine.com>
 
>>   - less power than C++ provides = since you don't mention
>>   performance as a number one priority [NB Java/Python/etc are
>>   often within 5% of the performance of C++ these days -
>>   sometimes faster [normally better at memory management]]
 
> I don't buy that Java or Python are "often within 5% of the
> performance of C++", unless you hand-pick the worst C++ coders you
> can find.  I also reject the claim that they are "better at memory
> management".  GC != "better memory management".  In fact, RAII is
> very nearly optimal usage of memory in most cases, is easy to make
> exception-safe, and doesn't stall your application while the GC
> thread kicks in.  And if you really feel you need the crutch of
> GC, you can always use a GC lib in C++.  However, you can never
> use manual allocation in Java or most other GC langs, even if you
> know there are places where it would significantly improve
> performance (and something like a MUD is an app where you are
> quite likely to be able to identify such cases).  >

If you want a deeper discussion, I suggest private mail rather than
risk spiralling off-topic, but I think I was probably just unclear
in what I was saying, so a quick explanation:

  1. "often", not "always". Bear in mind that server-JVM's today do
  feedback-directed compiler optimization on just-in-time compiled
  code (mouthful). I.e. they recompile the same java bytecode into
  assembler/object-code/equivalent multiple times over the course of
  hours/days/weeks, seeking the most optimal set of
  compile-optimizations. This is the same process people use to
  improve their SPECint benchmark results (www.spec.org) - except
  AFAIAW this is not a "standard feature" of their C++ compilers,
  its somethign achieved with special harnesses? My understanding is
  that the reason the likes of Intel/HP/Sun/etc do this is because
  ultimately it produces the best compiled code possible? And from
  what I know of formal compiler-optimization techniques, there's no
  way a "typcial" C++ compiler could do better?
  
    Personally, I consider the only real problem area performance
    wise to be when trying to optimize code so that a loop fits in a
    cache - as you rightly point out, impossible in Java (at least
    thats what I assume you mean by "manual allocation"). But these
    cases are not IME an issue at all unless performance is a very
    high priority - which as I noted is apparently not the case?

  2. All standard Java VM's (e.g. all of Sun's standard free ones)
  have extremely good memory management - I've seen tests performed
  on datasets of upwards of 100M in size, showing Java losing out to
  e.g. MSVC++ in the lower end of memory used (due obviosuly to
  things like better use of caches), but then performing better with
  the massive memory usage (the upper end may have been 256Mb, maybe
  512?) due to techniques the JVM was applying automatically,
  without the code even having to be aware of it. I'm sure there are
  very good memory management solutions available for C++, but are
  they all free? Does the typical "good" C++ coder know of and use
  them? Shrug.

Garbage collection is a wonderful piece of functionality, yes, but I
wasn't referring to it at all - except that a side effect of using
it is that you let the VM do all the clever management for you.

Hmm. Not so brief an explanation, but hopefully it makes my point
clearer?

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev