Re: [Vala] reference management.

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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]