[gameprogrammer] Re: Scripting engines: Upvalues and function refs
- From: David Olofson <david@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Wed, 14 Apr 2004 13:27:05 +0200
On Wednesday 14 April 2004 10.51, Julien Pauty wrote:
> Bob Pendleton wrote:
>
> Sorry for cutting the rest of the thread but I will talk about the
> GC
>
> >On Tue, 2004-04-13 at 04:52, David Olofson wrote:
> >>On Monday 12 April 2004 21.59, Bob Pendleton wrote:
> >>[...refcounting and/or GC...]
>
> Maybe this will give you some ideas for you GC problem :
>
> I have been working on a GC and related stuff for my master degree.
> It was about checkpointing Java programs. The JVM was dedicated to
> mobile devices running multimedia applications. So, we are in the
> soft real time situation. To ensure a regular execution (for the RT
> aspect) the choise to execute the GC explicitly has been done. One
> asumption is done : the program has some sort of main loop. The
> idea is to call the GC at the beginning of each iteration of the
> main loop. Of course, to reduce the overhead it is possible to call
> the GC every ten or hundred iteration. The drawback is that the
> developper has to call the GC explicitly in his app.
No problem. I'm dealing with "frame based" applications here (audio
frames, sample frames or whatever), so there are natural places to do
some GC or other background work.
> The GC is a "mark and sweep" one.
Ouch. A basic mark & sweep GC is a major showstopper in hard RT
systems. It has to be some form of incremental variant, so you can
control how many cycles it burns before you get back to executing
application code.
> It tracks live objects by
> following references between objects. References are easy to track
> in Java since they are explictly defined by the langage as a type.
> In this way an object's field can be intergers, floats, references.
Most languages do that, at some level, but that's not all there is to
it... However, my "values" (constants, variables, registers etc) all
have type info in them, so I could basically just look at any element
and see exactly what it is, at run time. (It's still 100% dynamically
typed; that's why...)
> The GC just examines the objects' fields and follows the
> references. Every time an object is created by the JVM, its
> reference is added to the "live object" list in the GC. When the GC
> do its references tracing it move the identified object from the
> "live objects" list to the "dest list". Finally, the objects
> remaining in the first list are "dead" objects and can be deleted.
Problem is that that algorithm breaks down if you interrupt it in the
middle, mess around with some objects, and then get back to GC. It
gets quite a bit more complicated if you have to do it incrementally
(which is required in a hard RT system, unless you can somehow have
bounded GC time by other means) - but of course, the basic idea is
still the same.
> Maybe you could have a similar notion of reference in your
> language. Having a type for "pointer between object" is a
> convenient way to track link between objects.
Right.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
Other related posts:
