Re: A Tale of Two Memory Managers (long)

From: Per Larsen (perATportablemindsDOTcom)
Date: 06/08/04 

Date: Tue, 8 Jun 2004 12:08:34 +0200

"Dennis Landi" <none[at]none.com> wrote in message
news:40c56284$1@newsgroups.borland.com...
> Let's take stock.

Interesting topic. A few comments.

> A) I have seen some argue that the problem is with the JITter because
the
> code is compiled upon execution (on start up). Nah, I don't see that as a
> serious argument, but if others would like to make the case for this -
> please do.

If nobody cared how long a .NET app took to load, sure, the JIT compiler
could emit close-to-optimal code. But obviously people do care about load
time, and so the JIT compiler is forced to use template-based code
generation, which is very fast, but generates far from optimal code.

.NET comes with the NGen utility, which is a utility for pre-compiling
assemblies. Ironically, the purpose of this utility is solely to cut down on
load times where even the current, fairly simple-minded (and thus, fast)
code generation isn't fast enough. In fact, Microsoft says that NGen'd code
is even likely to be (slightly) less efficient than normal JIT-generated
code, which makes sense because NGen lacks exact knowledge of memory layout
of any referenced assemblies, and so on. In theory, however, a future NGen
utility could spend much more time analyzing than the JIT'ers and therefore
emit code of higher quality.

> B) Others argue that current JITters simply don't do a good job at
> efficient compilation against current day native compilers; and will never
> do better than deliberately hand optimized code. Well, I'll buy that.
Does
> anybody have technical arguments, yay or nay, that they would like to
offer?

Apparently, there is quite a bit of research going on in this area at the
moment - not just by Microsoft, but at various universities as well. Well,
it's obvious that at the local level, it's not really possible for any
compiler to "do better than deliberately hand optimized code" since a human
can do anything by hand that a compiler can do. In most cases, however, hand
optimization is prohibitively expensive. This is becoming even more of an
issue how as we see a departure from the common IA86 instruction set we've
used for the last decade; AMD64 and Itanium code is *very* different.

> D) And then the next and most compelling argument is the tale of the
two
> memory managers. It is my opinion that the reason why .NET can never be
as
> performant as natively compiled code actually has NOTHING to do with the
> JITter, at all. I suspect it has everything to do with the .NET Garbage

Well, I suspect that this will be highly dependent on the exact type of
application being discussed. In my personal experience, the significant
slowness of .NET code hasn't been caused by garbage collection but by
inferior native code. Memory allocation alone (disregarding dispose/GC for a
moment) is actually quite fast in .NET. Faster on average than in WIN32
apps.

I do agree with some of your points regarding this topic, however:

> In no way is a GC needed to realize the larger vision of .NET.

True

> I think that the belief that being able to create objects at will without
the responsibility to free them - is somehow a step forward is simply
fallacious.

Agreed. The programmer *must* understand what's really going on. If s/he
doesn't, there's going to be trouble down the line - no matter what.

> The ability to deterministically free memory and return it to the heap at
will is a Good Thing [tm].

Agreed.

> The GC advocates will argue that all the time spent hunting for memory
leaks
> due to various programmer errors code be better spent on PRODUCTIVITY
> afforded by a mechanism that just manages and reclaims discarded memory.
> Ok, well that's fine as far a the *idea* goes. But the trade-off is
> PERFORMANCE.

Not only that. .NET and garbage collection doesn't really do away with
memory leaks at all. It does cure the dangling pointer crash because memory
isn't freed as long as the reference exist, but the very common issue of
holding on to references after you've finished using the memory often cause
.NET apps to use way more memory than their native counterparts.

What puzzles me, personally, is that the argument that "tracking down memory
leak problems is difficult and time-consuming" often comes from the people
who make the compilers but who never made any serious attempt to help the
programmer in that regard. For example, why aren't memory leaks considered
errors by the Delphi compiler and RTL? Like most other bugs, leaks are
easiest to deal with right after they're introduced - when the code is still
fresh in the mind of the programmer. Some common types of memory leaks can
(could) even be detected at compile-time.

There are places where automatic garbage collection is very handy, however.
Operator overloaded classes and fire-and-forget delegates come to mind.
Ironically, the latter will leak in some cases because of a bug in the .NET
garbage collector, apparently.

Perhaps a hybrid solution would be ideal where you got to specify by type
whether manual or automatic memory mode should be used.

- Per

Relevant Pages

  • Re: WWDC -- MacBook Pro?
    ... ....but once the program has loaded it into its program memory, ... boundaries, int16 are aligned on 2 byte boundaries, int32 are ... people are always able to come up with the compiler ... Case B, same glass, same ice code water.  ...
    (comp.sys.mac.system)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)
  • Re: Compiler and How It Handles Scope
    ... VB's compiler isn't really "state of the art" David. ... memory, no matter how many processes map the code into their virtual address ... words, no real distinction is made between Public/Private variables, or even ... > Modules can contain Public and Private variables, ...
    (microsoft.public.vb.winapi)
  • Re: WaitForSingleObject() will not deadlock
    ... Whatever memory values a thread can see when it creates a new thread can ... that later locks the same mutex. ... standardized multithreading library designed to run efficiently on existing ... A C compiler is not required to do this, and it can still be a conforming C ...
    (microsoft.public.vc.mfc)
  • Re: Delphi for XCode?
    ... memory, and that it moves blocks when they are promoted to the next generation, ... Of course you can have the compiler execute e.g. an array of events. ... But what does COM have to do with MY interfaces? ... Mono is using Boehm as well. ...
    (borland.public.delphi.non-technical)