Re: [Vala] reference management.

[Jürg Billeter <j bitron ch>]

On Die, 2007-03-20 at 18:17 +0000, jamie wrote:
> On Tue, 2007-03-20 at 18:32 +0100, Jürg Billeter wrote:
> > On Die, 2007-03-20 at 07:18 +0100, Mathias Hasselmann wrote:
> > > Currently all member variables are strongly referenced by default. To
> > > make them weak add exactly this keyword. For local variables currently
> > > some heuristics exist. Weak still is preferred, but there are some
> > > thoughts to use always use strong references for local variables.
> > > Problem with strong references on local variables: Whilst strong
> > > references are quite cheap to maintain for GObject derived classes,
> > > they can be extremely expensive for things like boxed types or GList.
> >
> > I've removed the heuristic from Vala SVN; local variables default to
> > strong references now. The compiler will warn if it has to copy
> > structures without support for reference counting as that might cause
> > side-effects and might also be expensive for some types. You can still
> > explictly specify local variables to be weak, so that you can optimize
> > critical code parts if necessary.
>
> 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.

> > 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.

> 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.

> 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.

> 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.

> Also if g_thread_init has not been called it might be a good idea to use
> non-threadsafe ref counting which should be a lot faster - hopefully
> glib will accept a path for that too!

Yes, I don't know whether that check would be performance critical or
not, i.e. we don't want to decrease the performance in the multi-thread
case. Non-threadsafe reference counting would ceratinly be a lot faster.
I will ask glib devs about possible solutions.

Jürg