Re: [Vala] reference management.

[jamie <jamiemcc blueyonder co uk>]

On Tue, 2007-03-20 at 21:26 +0000, Jürg Billeter wrote:

> > I would recommend sending patches to glib for ref counting for all the
> > glib data structures (as GHashTable has it Im sure they will accept it
> > for all the rest if its done in the same way)
>
> The problem is that some structures are not opaque, so (efficient)
> reference counting can't be added without breaking the interface.
> GString, GList, and GQueue are all not opaque.

%^"&!

It would probably only break language bindings if we extended the
interfaces but I guess thats unacceptable to the devs.

Looks like you will have to fork them then until we get a glib 3!

> > > We intend to add a full garbage collector to Vala which can be used as
> > > alternative to reference counting as far as possible with GObject. This
> > > might improve performance without manually marking weak references.
> >
> > Will the GC be compatible with platform stuff though?
>
> Our GC design allows Vala applications/libraries to access non-GC
> libraries and it should also allow to be used by non-GC applications. It
> effectively only tracks references related to classes written in Vala.
> The implementation hasn't been finished yet, though, so we haven't been
> able to test our design in practice.

I was thinking a string created in vala that needs to be freed by a
non-gc app. I guess you could remove it from the GC roots if its exposed
that way.

> > Also the GC will add runtime requirements and typically double memory
> > usage. However its still nice to have as an option...
>
> It won't double maximum memory usage as it's not a moving garbage
> collector and even moving garbage collectors only require double memory
> for a short amount of time. The runtime requirement might be an issue
> but we'll definitively continue to support the current memory management
> system, the GC will be optional.

well the bog standard Boehm GC (as used in gcc/gcj) is notorious for not
being agressive enough in recovering memory quickly so it tends to
double memory usage because of that (also fragmentation of the heap does
not help either)

If you can find a high quality GC then yes you might get away with much
less memory overhead

GC is only really a must if you have circular refs. Having a circular
ref checker in Vala would probably be needed in the future anyhow (if
only at debug time) 

Another disadvantage of a runtime GC is that you will also need to add
finalization (dispose) to certain objects which will be needed to free
non-memory resources like file handles in a GC environment. 

I would hate having to call dispose if I was using ref counting!
(hopefully you can find a way round that)


> > I would personally use GString (with ref counting patch to glib) as the
> > basic string type in vala as that this can be managed efficiently
> > without copying strings via default strong refs. Its also a lot faster
> > for string concatenation as it allocates extra memory for potential
> > string growth in chunks (using gslice I believe)
>
> Our standard strings are usually considered constant as in Java and C#.
> GString corresponds to StringBuilder and should be used for string
> manipulation. As mentioned above, we can't use GString as default due to
> missing reference counting.

yeah I know but using strdup on all non-weak string refs is going to
really harm performance. 

> > For C interfacing, a cString type should be used with the compiler
> > automatically converting  from GString to cString just like Delphi does
> > with its strings.
>
> We'll certainly look into supporting automatic conversion between a
> reference countable string type and standard c strings. I haven't
> checked yet where potential problems lie.

great Im sure that will help speed up vala apps!

jamie.