Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Sun, 2003-08-03 at 03:44, Mathieu Lacage wrote:

> Le dim 03/08/2003 à 02:08, Owen Taylor a écrit :
> 
> > So, how do we fix the problem? Two ideas I can come up with:
> > 
> >  - increase GTypeInstance from 4 bytes to 8 bytes (on
> >    32 bits), caching the real type *before* the public g_class field.

Actually, it's from 4 bytes to 12 bytes since the result of
g_type_create_instance() needs to be maximally aligned - e.g,
so we can do;

 struct MyA
 {
   GObject parent_instance;
   gdouble foo;
 };

> >  - Use thread-private data to keep track of a stack of
> >    currently-being-initialized objects with their real types, and 
> >    have g_type_instance_get_private() check that.
> > 
> 
> I'd go for the thread-private stack: increasing the GTypeInstance size
> feels like unneeded overhead at all times when there is need only for
> specific overhead at one point in time (ie: initialization).
> 
> However, the cost in terms of additional implementation complexity might
> not be worth it (given the beauty of the current codebase, it might be
> worth not trying to make it any more beautiful :). Are there really
> people around who rely on being able to create thousands of small GTypes

My concern is not beauty, but rather efficiency; looking up a
thread-private data key isn't free (*), and
g_type_instance_get_private()
is intended to be just a few cycles. That already isn't the
really the case, which is why we are putting ->priv pointers into new
Gtk types, but I'm a little reluctant to make it worse.

Some timing is probably needed here.

The other advantage of the "bloat GTypeInstance" approach is that
this may not be the only problem of the form "G_TYPE_FROM_INSTANCE()
produces unexpected results in instance_init()". 

Regards,
					Owen

(*) With ultra-recent Linux/GNU libc/GCC, you can use __thread variables
which *are* pretty much free, but:

 A) We do need to consider performance on all platforms even if
    we have a fast way to do things in some places.

 B) We can't use __thread variables in GLib, even #ifdef'ed
    because of g_thread_init (my_vtable); They do accelerate
    g_static_private_get() indirectly, through the chain
    of
       g_static_private_get => g_thread_self => g_private_get =>
       g_private_get_posix_impl() => pthread_getspecific ()