Re: How to get Ada to ?cross the chasm??

[Paul Rubin <no.email@nospam.invalid>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> [ Since versions of Python are not compatible and ridden with bugs
> there is little use in whatever measurements on its implementation. ]

Sorry but I have to notice that every day, far more practical Python
code is being written than practical Ada code.  Sure Python 3 is
incompatible with Python 2, but nowhere near as incompatible as Algol 68
was with Algol 60.  Sure Python programs have bugs, but if you're like
most people who drive a car to work every day, you accept a nonzero
probability that your car won't start because you don't want to pay for
an ultra-reliable car built to NASA specifications.  Ada in the
practical world is an unpopular competitor to Python for similar
reasons.  

Anyway, the observation about locks affecting refcount manipulation
timing has nothing to do with the surrounding application.

> Low-level lists should not use reference-counting. E.g. I frequently
> allocate lists in an arena pool.

So you delete all the lists at the same time?  What if you have two
5-element lists, (a b x y z) and (c d x y z) where both share the same
3-element tail?  You might be finished with the first while wanting to
continue using the second.  Even if you disallow circular lists, you
still probably want something like refcounting.

> But measuring GC vs. alternative memory management must be exact and
> it is a very difficult problem in itself.

It doesn't sound difficult for a short benchmark if you have enough
memory.  You can turn off GC completely, so when you allocate memory it
is never freed until the benchmark finishes.  Then the GC time is zero
and you can compare the runtime to running the same program with the GC
enabled.  Although, it might be faster with GC turned on, because of
caching.

Ben Zorn in the 1990s did a lot of tests where he captured complete
execution traces of programs using different GC methods.  It should be
possible to classify all the primitive operations in a trace and count
up the ones that are part of GC.  I don't know if he did that though.

> That depends on the implementation. I keep the list of weak references
> in the object itself, so there is no heap memory involved.

Do you mean a count of weak references (along with the count of strong
references), or do you chain all the weakrefs together somehow, so you
can find them all and invalidate them when the object is freed?

> If you can track pointers statically you need no pointers at all. You
> just track the objects instead.

I mean the compiler knows the memory layout of each datatype, so if the
datatype contains pointers, it knows where they are, and it knows the
types of the pointed-to objects.  That means starting from some known
objects with known types, the GC can recursively find all the reachable
objects and reclaim the unreachable memory.  That's in contrast with
conservative GC where the runtime can't necessarily figure out the types
of all the objects.  Conservative GC is a terrifying concept in theory,
but it works surprisingly well in practice.  It has been used in Ada in
the past.