All geek questions in one place

Garbage collection with glib?

I would like to associate the garbage-collected language (in particular using the venerable Boehm libgc) for the glib API family.

glib and gobject use internal reference counting to control the lifetime of an object. The usual way to wrap them is to use a garbage collected peer-to-peer object that contains a reference to the glib object and which discards the link when the peer completes; this means that the glib object remains alive while the application uses peer. I have done this before, and it works, but it is rather painful and has its own problems (for example, creating two peers of the same base object).

Given that in any case I have all the overhead of a garbage collector, ideally I would just like to turn off glib link counting and use the garbage collector for everything. This will simplify the interface endlessly and hopefully improve performance.

At first glance, this seems pretty simple - connect the garbage collector finalizer to the glib object finalizer and redefine the ref and unref functions, which will be noops --- but further research shows that this is more than that: glib likes to keep its own allocator pools, for example, and, of course, I let him do that the garbage collector assumes that everything in the pool lives and it will flow.

Is persuading glib to use libgc is actually doable? If so, what other errors can I encounter? What is the impact of glib performance forcing all distributions to go through the libgc product (as opposed to using optimized distributors currently in glib)?

(Glib docs say it should interact cleanly with the garbage collector ...)

+6
source share
3 answers

Not.

Asking about this, I found that libgc is not looking for memory belonging to third-party link libraries. This means that if glib has in its workspace a single reference to an object allocated via libgc, libgc will collect it and then your program will crash.

libgc can only be used on objects belonging to the main program.

0
source

http://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html is old but still relevant.

Learning how language bindings (proxy objects, switch links) work is likely to be useful for this.

Update: oh, upon hearing the Boehm GC, I thought you were trying to replace g_malloc, etc. GC, as in this old post.

If you are binding to a language (not GC'ing C / C ++), then yes, this is very achievable. A good example for reading is gjs (SpiderMonkey JavaScript) code.

The basic idea is that you will have a proxy object that "stores" GObject and often has a single link to GObject. But one difficulty is link switching: http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00095.html

You need to save the proxy object in GObject so that you can return it (let's say someone does widget.get_parent (), then you need to return the same object that was previously set as the parent by extracting it from C GObject). You should also be able to move from a mediation to object C. Obviously,

+2
source

For future visitors, you can refer to this article (not mine): http://d.hatena.ne.jp/bellbind/20090630/1246362401 .

It is written in Japanese, but the code is readable.

The compilation options mentioned in https://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00133.html may also work, I have not tested it myself.

And one more problem with G_SLICE if you came across it: http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2011-January/004289.html .

0
source

Source: https://habr.com/ru/post/889795/

More articles:


All Articles