One problem with the Java approach of start with a bad GC, then
develop good ones later, though, is that it let Java users develop a
poisonous culture of writing finalizers that must be run in a timely
manner.  This worked at first, but introduce generaltional GC, and
suddenly you've got unreleased resources in older generations that
aren't being collected.  Active Java users would probably have a
better idea about how much of a problem this still is, but any code
base that does this pretty much requires a poor GC.

Oh, and to answer your question, I don't know of any, but if you look
for papers on Java GCs, you'll often find references to papers on Lisp
GCs.  So, there's comparison of a sort.

:)

[...]

Finalizers are one of my pet peeves with Java; more precisely, the
fact that Java doesn't have destructors. People coming from a C++
tradition look for the destructor, don't find it, and use the
finalizer. The only good use i can think of for a finalizer is to
release memory that has been malloc-ed outside of the garbage
collector (perhaps as part of a native interface method). Stay away
from finalizers -- they're evil.

Now, not having a destructor, we're forever having to code stuff like:

try { open database connection, do stuff }
finally { close database connection }

when this should have been handled transparently in the destructor.

Andreas

If Java had some sort of stack-based "struct" type, such a thing could have
scope-based destructors. But such things would not fit with the rest of Java,
by-value/by-reference/identity issues would arise, etc.

I want scope-based destructors too, but what I would do is to add to Java a
sort of compromise: have a scope-based construct that does not complicate
Java's type system but yet allows the programmer to easily express scope-based
management (essentially a form of Lisp-style with-xxx macros):

  Connection c = new Connection(...);
  with (c)
  { ...do stuff...
  }

Such a construct would be equivalent to:

  Connection c = new Connection(...);
  try
  { c.initializeResource();
    ...do stuff...
  }
  finally
  { c.finalizeResource(success);
  }

with the added requirement that c implement some sort of ControlledResource
interface that mandates the initializeResource() and finalizeResource()
methods.

Then the decision of when to "destruct" is up to the programmer (this is the
compromise), but things are easy to express, making it straightforward to
repeat a "managed scope" while minimizing the possibility of introducing an
error in the resource management logic.

Followups to comp.lang.java.machine where this kind of thing can be better
discussed [and is a counterpoint to Edward Diener's current proposal for a
resource type].

In article <3216205787209...@naggum.net>, Erik Naggum  <e...@naggum.net> wrote:

Yes, I *know* that I don't know all of C++. Who does? Just read those
Guru of the Week thingies or similar in comp.lang.c++.moderated.
Read some strange template-based code. etc.

Still, I know enough of C++ to program useful things. It's more effective
than pure C, I guess. Perhaps if I had already invested the same
effort into e.g. Lisp, I'd be even more productive. However, alas,
technological merits aren't the only things that count in industry.

In C++ you say std::map<KeyType, ValueType>. In Java you just use some
map type and have to cast values you retrieve dynamically to the type
you expect. You have to slightly cheat around the type system in Java
in this case. (There are Java extensions that fix that deficiency,
and AFAIK the solution of generic classes is in fact cleaner than C++'s
templates.)

Kind regards,

  But things that are true _now_ which turn out to be false a short time
  later are generally regarded as unpredictable.  The problem is that you
  have to make those changes without any changes in external requirements,
  they are required as your knowledge of only your _own_ code increases.  I
  consider this to be a case of being forced to say that something is true
  when you are clearly not certain that it is, and then when you cannot
  make up a credible world around it so it holds true, you change your
  testimony, as it were.

| Now, frankly, C++'s type system is usually more expressive.  You can map
| almost everything save for GC-based issues from Java into C++, but not
| necessarily vice versa.

  This is actually an argument that C++ is a lower-level language than
  Java.  The most expressive type system is that of machine language, or
  assembler.  We sacrifice expressibility on one level to attain it another.

| However, I don't really like using such simple drawers like "male" and
| "female".

  People actually do come in these easily labeled packages.  The difference
  is whether one confuses the descriptive and the prescriptive statements.
  Induction is a tricky business, prediction even more so.  I really tried
  to avoid both and just report my observations so far.  See my signature
  for a hopefully succinct summary of all the possible arguments why I
  think you misdirected your comments on stereotyping.

        (with-open-database-connection (conn) (do-stuff conn))

Destructors are not necessarily the answer. Using the destruction of an
object to clean up its state is a really semantic hack; in C++ you force
the destruction of the object in order to make it close the database
connection that it manages as a side effect.

        (with-open-database-connection (conn) (do-stuff conn))

Destructors are not necessarily the answer. Using the destruction of an
object to clean up its state is a really semantic hack; in C++ you force
the destruction of the object in order to make it close the database
connection that it manages as a side effect.

Actually, I think that the only interesting property of any language
is a sufficiently hairy macro system.  Who needs to actually compute
anything when you can expand macros.  C++ seems to be realising this
with templates.  They haven't quite got there yet, but fairly soon
they'll work out that you don't need to ship the system at all, you
just ship some *really complicated* templates, and the compiler.
Soon, to boot windows you'll just say `gcc windows-xp.cpp > /dev/mem'.

Have you measured GC overhead recently?  Will Deakin & I did some
tests (he did most of them) for a fairly consy program on a number of
machines & CL systems.  I think the worst was ~6% runtime, the best
was 2 or 3%.  None of these were tuned at all, I'd guess that for a
highly-tunable system like ACL (which I think was at the low end
already), you could likely shave another couple of percent off,
leaving you with maybe 1-2%.  It's in the noise.

The reason this is slighly tongue in cheek is that one place where
there probably are big wins are GCs for multithreaded systems on
multiple-processor machines. a GC that takes 5% and serialises the
program will start to hurt at 20 processors, which is not very large
(though not exactly a desktop either).  And Sun have a big interest in
a multithreaded system (Java) and multiple-processor machines, so
there may be interesting developments there.  However I'm not sure if
that problem is not already mostly-solved in academia.

The problem of the

try { do something with the database }
finally { release resources }

is that it's verbose, and people forget to do it. Many Java
programmers never use the finally clause of the try block (i know...).
Specifically with databases, sometimes it's not clear what you need to
release (statements? result sets? all of the above?). I've worked with
a buggy driver (IBM's DB2 level 4 driver) that locks up when you try
to release a result set. :-( This leads to bugs that are hard to
reproduce, because depending on your application's memory usage, the
finalizer may indeed be called and release the resource for you (or
not, depending on how the driver's developer coded it).

In Java, the only way to extend the language is by subclassing.
Sometimes this forces people into a better design, but sometimes the
mechanism is just not powerful enough.

[*] I'd suspected that dynamically-typed languages are better for GC
because statically-typed ones encourage the programmer to do some
manual memory management by holding on to some stuff that's probably
garbage, and generally forcing the programmer to think more about when
they get things and let them go.  This might just be an artifact of
the code I've seen from others (I don't think I could make that
judgment on my own code very well), but I think I read a paper that
confirmed my suspicions.  I say "I think" because I can't find it
(moved 3 times in the last year), and without double-checking, I
might've been just hearing what I wanted to hear :-)

Andreas

 > but I still can't get around the fact that I sometimes need to
 > do memory defragmentation and sweeps of Generation 2. Each of
  > these operations, which I usually run 1 or 2 times an hour in
  > peak load hours, will last for about 10 - 30 seconds. For my
   > specific application, a 30 seconds "blackout" once an hour
is  > fully acceptable, but for other applications it's not,
Speaking from a position of complete ignorance -- often an
advantage -- your descriptions indicates that you are using a
form of generational gc. Would it not be more appropriate to use
a non-generational gc?

For the issue of multiprocessing GC, there's code available in the
Boehm-Weiser conservative GC.  It supports parallel marking in
multiple threads.  This GC is used by Java, Scheme, ML and Dylan
implementations.

Andreas

    http://www.ai.mit.edu/~jrb/Projects/java-macros.htm

Michael

If everyone brings his pet Java peprocessor to a project, you end up
with code that is going through half a dozen text filters to produce
executable code. What if, for instance, you want to use AspectJ
and the Java Syntactic Expander at the same time?

A similar thing was done for C++ as part of Edward Willink's
Ph. D. thesis.  ``Flexible Object Generator'' (FOG).
http://www.computing.surrey.ac.uk/research/dsrg/fog/

The creator of Java, James Gosling, wrote a structural macro preprocessor
for C called ACE, over ten years ago.  Its aim was to perform code
transformations with the primary aim of doing optimizations that the
compiler isn't trusted to be able to do.
http://java.sun.com/people/jag/ace/ace.html

Michael