[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jan 3 23:55:58 2004 
Subject:Re: Comparing Garbage Collectors 
From:Roger . Evans 
Volume-ID:1040103.01 

Hi all,

happy new year!

Stephen Leach wrote:

>Hi,
>
>David writes about oldarray:
>  
>
>>I thought I'd mention my contribution to this, since it took a lot of
>>thought to get it right, but I believe I did get it right in the end.
>>    
>>
><snip>
>  
>
>>http://www.cs.bham.ac.uk/research/poplog/popvision/lib/oldarray.p
>>http://www.cs.bham.ac.uk/research/poplog/popvision/help/oldarray
>>    
>>
>
>That is very clever - a reallocator that cooperates with the GC.
>
>But this might be a stupid idea but I'll suggest it anyway.  Why not
>invent a special tag type like this?
>
>  ;;; Choose a better name ... this name chosen to match the
>  ;;; documentation.
>  defclass OldArrayTag {};
>
>  procedure( bounds, tag );
>      oldanyarray( tag, bounds, vector_key )
>  endprocedure -> class_apply( OldArrayTag_key );
>
>And you get this idiom:
>
>  lconstant oldarray1 = newOldArrayTag();
>  ...
>  lvars array = oldarray1( bounds );
>
>I think it is a more elegant way to package up the tag.  The tag now represents
>a reallocator which is quite a nice idea.  You've lost nothing because you
>can still write
>
>  oldanyarray( oldarray1, bounds, key ) -> array
>
>for the full generality.  But maybe I am just missing the whole point ..... ?
>
>  
>
Steve, the idiom you suggest here is neat - the implementation is 
perhaps slightly screwy because you are building on top of the existing 
oldanyarray so it feels like there's a little redundancy - couldn't you 
achieve this effect with a closure and avoid the need for any other tag 
(but that would require changes to oldanyarray itself ).

I'm reminded of the idea of user-assignable class constructors (at least 
I think it's a reminder - I can't be the first to have thought of such a 
thing :-) ) so that one could implement freelists (etc) system wide on a 
per class basis - temporary properties/destroy actions etc would allow 
them interact smoothly with the GC (perhaps this idea has not been aired 
since such facilities were available?). But of course that wouldn't 
achieve David's goal, because it is key based and he needs something 
more fine-grained. A general library, say *class_create*, which 
parallelled class_cons except for the addition of a tag element as final 
arg would be enough of an API (the default being to ignore the tag - 
David has provided an implementation for array_key as a start), and 
might be useful enough to migrate into the system in some places one day.

Of course, trying to make memory allocation more intelligent opens up 
profiling questions. Currently the system profiles GC time, but perhaps 
we would want to start profiling allocation time too.

roger