[Commotion-dev] [commotiond:obj] Garbage collection and object flags initial proposal (w/ notes on lua roadmap)

[Josh King]

Hi Luis,

I'm trying to fully understand how this will work; forgive me, I haven't
ever written lua bindings for a C library before. If it helps, I can try
and describe how memory management happens right now in libcommotion.

All objects are explicitly allocated and explicitly destroyed by the
caller; the library does not attempt to do garbage collection on its
own. The only instance where there is anything resembling garbage
collection is in the use of the halloc allocator, which is used
throughout the library. Halloc allows you to assign a particular block
of dynamic memory as the parent of another block of dynamic memory. This
allows one to build data structures (as we have done with co_list and
co_tree) where each object inserted into it is associated with the
structure, so that when the structure is freed, every one of its member
objects is freed as well. Again, the caller controls the use of this
functionality, as there are _unsafe insert functions that allow you to
insert an object without it being linked to the object as a whole. We
use this to queue up objects for the network socket without having to
worry about accidentally freeing the originals.

So basically I'm trying to figure out if there are any instances where
something that gets passed through the stack to lua will be the
responsibility of anything other than one of the 'actors' i.e. the
caller. And if so, something is getting passed through that has
ephemeral state or is static, whether we need to signal that or whether
that is an indication of a bug in how the library is handling that piece
of memory.

On 07/17/2014 06:16 PM, Luis EG Ontanon wrote:
> the Lua interface is on its way...
> 
> First I'm coming out with a full wrapper for commotionlib, that should
> allow to write a full blown client or daemon in Lua. Later, as I get
> more acquainted with the API I will think in how to get it to work in
> a "modular" way "within commotionlib".
> 
> In the next few days I'll be done with the code generator and within
> the next few weeks the LuaAPI should be compiled and ready for the
> next step:
> 
> To run leaking almost everything... to allow me to understand what's
> needed for correct garbage collection: The issue is that Lifespan of
> different objects, differs from their presence in Lua, some exist only
> while "in Lua" (and get destroyed by it) some others are to be
> delegated to someone else, while some are just to be left alone).
> 
> It is evident to me that the solution to the problem goes through how
> to use the flags field of co_obj_t .
> 
> The key to successful memory management is having a clear idea of who
> is to take care, when and how,  of the destruction of objects ( "the
> trinity" of garbage collection).
> 
> So evidently what we need to convey in the flags field is enough
> information to be able to easily come out with this "trinity".
> 
> I was thinking in using few of the LSBs to convey "who" is delegated,
> an leave the MSBs to "the delegate" as each one has its own demands.
> 
> some of the values I'm thinking for the "who subfield" are:
>  - "somewhere in the stack"... a return will destroy it... (useful to
> know as I may want to make my own copy if it has to predictably
> persist)
>  - "no one" static object.. will persist forever..
>  - one of some "actors": e.g. the Lua machine, This or that module.
> 
> In this scenario and we need to define some methods to delegate between actors.
> 
> Cheers,
> \Lego
> 

-- 
Josh King
Lead Technologist
The Open Technology Institute
http://opentechinstitute.org
PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20140729/ef8faf50/attachment.sig>