dream garbage collector

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dream garbage collector

John Belmonte-2
Hello,

There has been talk about alternate Lua implementations, but what I'd really
like to see is just an alternate garbage collector for the TeCGraf
implementation.

For example there is an incremental non-copying collector [1] that may be a
good fit, allowing use of Lua in real-time applications.  Combined with a
solid method for adjusting the work done per increment [2], GC control would
be almost fun.  Just specify the amount of wasted memory to be tolerated as
a percentage of in-use memory, with higher tolerance translating to lower GC
overhead.

-John


[1] ftp://ftp.cs.utexas.edu/pub/garbage/GC93/wilson.ps
[2] http://www.fridi.de/rts/papers/ismm98_corrected.pdf



Reply | Threaded
Open this post in threaded view
|

Re: dream garbage collector

Gavin Wraith-2
On Thu 15 Feb, John Belmonte wrote:
 
> There has been talk about alternate Lua implementations, but what I'd really
> like to see is just an alternate garbage collector for the TeCGraf
> implementation.

Sorry to make fuss about something as trivial as language,
but surely you mean "alternative" not "alternate". A copying garbage
collector will alternate between two heap spaces, or a mark-sweep
garbage collector will alternate between the mark and sweep
phases, but I suspect that this is not what you meant. Alternate
as an adjective usually means "the other of two" not "different".

-- 
Gavin Wraith ([hidden email]) or ([hidden email])
Home page: http://www.wraith.u-net.com/


Reply | Threaded
Open this post in threaded view
|

Re: dream garbage collector

Reuben Thomas-3
In reply to this post by John Belmonte-2
> There has been talk about alternate Lua implementations, but what I'd really
> like to see is just an alternate garbage collector for the TeCGraf
> implementation.

This ties in with my (seemingly ignored!) suggestion about componentizing
Lua, or alternatively put, specifying some of its internal APIs. The GC API
was one of the things I suggested formalizing.

-- 
http://sc3d.org/rrt/
"Reality is what refuses to disappear when you stop believing in it" -
Philip K. Dick


Reply | Threaded
Open this post in threaded view
|

Re: dream garbage collector

John Belmonte-2
Reuben Thomas wrote:

> This ties in with my (seemingly ignored!) suggestion about componentizing
> Lua, or alternatively put, specifying some of its internal APIs. The GC
API
> was one of the things I suggested formalizing.

I don't think it would be easy... especially not before we have experience
plugging in a few different GC's.

For example the incremental collector I mentioned uses write barriers,
meaning some bookkeeping needs to be done when a structure is altered.  That
affects the VM, table implementation, etc.

-John



Reply | Threaded
Open this post in threaded view
|

Re: dream garbage collector

Edgar Toernig
In reply to this post by Reuben Thomas-3
Hi,

> John Belmonte wrote:
> >
> > There has been talk about alternate Lua implementations, but what I'd really
> > like to see is just an alternate garbage collector for the TeCGraf
> > implementation.

All alternative garbage collectors I know require read and/or write barriers.
And that either requires hardware support or would slow down Lua a lot.

My opinion (a lot of people will not agree *g*): I would never use a garbage
collected system for hard real-time applications, whatever the designers will
tell me ;-)  And soft real-time may be done with a GC if you know how to
handle that beast :-)  (That may be another good topic for an LTN: How to
use Lua in soft real-time apps.)

Reuben Thomas wrote:
>
> This ties in with my (seemingly ignored!) suggestion about componentizing
> Lua, or alternatively put, specifying some of its internal APIs. The GC API
> was one of the things I suggested formalizing.

About GC: it's very tightly integrated into Lua.  And this tight integration
makes it pretty fast.  You can't really ripp'm apart to use it in some other
applications.  Removing the Lua specific stuff would leave nothing.  Same
for most other parts of Lua.  Or, did I understood you wrong and you want the
opposite - replace parts of Lua with other code - and have formalized inter-
faces do do that?  You could try that.  But I guess it will make Lua bigger
and slower.  Nothing that a lot of people are interested in.  If you are,
go ahead and show that it would be useful ;-)  I'm not convinced yet *g*

You once wrote about regexp for Lua.  Where's the problem?  I see no
problems in replacing Lua's pattern matching with regular expressions.
Are there any pitfalls that require changes to standard Lua?

Ciao, ET.