Re: [Vala] reference management.

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.


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