Steve Knight wrote
> Continuing the interesting discussion on languages with and without
> extensive runtime library support:
>
> Richard Matthias writes:
> > Yes, I am aware of the difference between interpreted and compiled languages.
> > ....
> .....
> I think that this is the key distinction that Richard is trying to
> define: the difference between languages with full automatic storage
> management and those without.
>
> This distinction is probably the most important characteristic of
> any programming language. When confronted by a new programming language
> I believe that one of the first questions a competent programmer
> tries to answer is: "how is store managed?"
>
> I believe that the distinction between languages with automatic and
> programmer-directed store management is archaic.
I am inclined to agree with this.
> ..It is time for
> programming languages to accomodate both techniques, so that programmers
> are able to deliberately "free" store or let it be automatically
> reclaimed as desired.
Pop-11 provides a tiny step in this direction with three procedures
sys_grbg_destpair
sys_grbg_list
sys_grbg_fixed
The last one, described in REF EXTERNAL_DATA, seems to allow much of
what Steve is asking for provided that you can put up with the cost of
structures that are not relocated by the garbage collector. (This will
slightly speed up garbage collection with the possible cost of
additional memory fragmentation.)
> ..Programming environments should come with tools
> that allow programmers to determine the memory-usage of their
> programs (e.g. to show that they will run in a garbage-free fashion,
I fear that as regards Poplog there's too much low level stuff in the
system and in libraries that generates garbage (e.g. the interfaces to X
and its utilities, and even the opening of device records for reading
and writing to pipes and files, etc.) for it ever to be possible to
ensure that one's code runs in garbage-free fashion in all applications.
However there are wide classes of programs for which that can be
achieved by using your own free lists of certain classes of structures
and using the above utilities and the recommendations in
HELP EFFICIENCY.)
Also it is worth noting that in some cases you can force garbage
collections at times when you think they are harmless in order to avoid
them at other times (though you'll still get store turn-over, and the
unpredictability of Unix environments).
> or see how the size of units allocated is distributed.)
I agree that this should be better supported.
> Firstly, Poplog should be supplied with a -sys_free- function that
> returns store to the managment system and constructors should be able
> to take advantage of the freed store (although for performance reasons
> this should be optional.)
sys_grbg_fixed and free_fixed_hold
provide a partial solution.
> Secondly, there should be more procedures
> for investigating the state of the heap: such as the amount of store
> allocated and deallocated. Possibly this should be done by making the
> constructors call some statistic gathering routines when -pop_debugging-
> is <true>.
Agreed. People who use fixed structures and external data will want to
know about the sizes (and locations ?) of the "holes" in the heap, as
they may sometimes be able to optimise these.
Aaron
|