smob gc protection, and inheritance

smob gc protection, and inheritance

[Doug Evans]

Hi.

I have a few questions about smobs:

1) Suppose I have some C code that creates a smob and its containing
SCM, but does not always expose the SCM to Scheme.

E.g.

struct foo_object
{
  int bar;
  SCM baz;
}

static SCM
make_foo_smob (void)
{
  struct foo_object *foo_smob = (struct foo_object *)
    scm_gc_malloc (sizeof (struct foo_object), "foo");
  SCM foo_scm;

  foo_smob->bar = -1;
  foo_smob->baz = SCM_BOOL_F;

  foo_scm = scm_new_smob (foo_smob_tag, (scm_t_bits) foo_smob);

  return foo_scm;  
}

If the caller stores foo_smob in the heap somewhere, and not foo_scm,
is that enough to prevent the object from being garbage collected?
Or should the caller be saving foo_scm?

e.g.

void
caller (struct another_struct *s)
{
  SCM foo_scm = make_foo_smob ();

#ifdef SAVE_foo_smob
  struct foo_object *foo_smob = (struct foo_object *) SCM_SMOB_DATA (foo_scm);
  s->xyz = foo_smob;
#endif

#ifdef SAVE_foo_scm
  s->xyz = foo_scm;
#endif
}

IOW, if I use SAVE_foo_smob, will my object get accidentally gc'd?


2) Is it possible to inherit, e.g., with goops, a smob?
IOW, can I extend a smob through inheritance?
Or must I store the smob in a class, and provide accessors?
[kinda like the "is a" vs "has a" relationship]


3) The docs aren't as clear as they could be on whether the "smob"
free function needs to scm_gc_free all results of calls to scm_gc_malloc
made when constructing the smob.  IIUC, this is not necessary.
However, why does the image example do this?

ref: libguile-smobs.texi:

size_t
free_image (SCM image_smob)
{
  struct image *image = (struct image *) SCM_SMOB_DATA (image_smob);

  scm_gc_free (image->pixels,
               image->width * image->height,
               "image pixels");
  scm_gc_free (image, sizeof (struct image), "image");   <<<<<<<<<<<<

  return 0;
}


TIA

Re: smob gc protection, and inheritance

[Ludovic Courtès]

Hi Doug,

Doug Evans <dje@sebabeach.org> skribis:

> I have a few questions about smobs:

I’m assuming Guile 2.x here.

> 1) Suppose I have some C code that creates a smob and its containing
> SCM, but does not always expose the SCM to Scheme.
>
> E.g.
>
> struct foo_object
> {
>   int bar;
>   SCM baz;
> }
>
> static SCM
> make_foo_smob (void)
> {
>   struct foo_object *foo_smob = (struct foo_object *)
>     scm_gc_malloc (sizeof (struct foo_object), "foo");
>   SCM foo_scm;
>
>   foo_smob->bar = -1;
>   foo_smob->baz = SCM_BOOL_F;
>
>   foo_scm = scm_new_smob (foo_smob_tag, (scm_t_bits) foo_smob);
>
>   return foo_scm;  
> }
>
> If the caller stores foo_smob in the heap somewhere, and not foo_scm,
> is that enough to prevent the object from being garbage collected?

Yes, because the region returned by ‘scm_gc_malloc’ is scanned by the GC.

> 2) Is it possible to inherit, e.g., with goops, a smob?
> IOW, can I extend a smob through inheritance?
> Or must I store the smob in a class, and provide accessors?
> [kinda like the "is a" vs "has a" relationship]

Presumably, at least to some extent:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> (use-modules (gnutls))
scheme@(guile-user)> (make-session connection-end/client)
$1 = #<session 2dcefe0>
scheme@(guile-user)> (use-modules (oop goops))
scheme@(guile-user)> (class-of $1)
$2 = #<<class> <session> 2e26000>
scheme@(guile-user)> (define-class <sub-session> (<session>))
scheme@(guile-user)> (change-class $1 <sub-session>)
ERROR: In procedure scm-error:
ERROR: No applicable method for #<<generic> change-class (1)> in call (change-class #<session 2dcefe0> #<<class> <sub-session> 2f33000>)

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
--8<---------------cut here---------------end--------------->8---

Andy can say more, I think.  :-)

> 3) The docs aren't as clear as they could be on whether the "smob"
> free function needs to scm_gc_free all results of calls to scm_gc_malloc
> made when constructing the smob.  IIUC, this is not necessary.

The ‘scm_gc_free’ function doesn’t need to be called nowadays, because
the GC automatically frees ‘scm_gc_malloc’ regions when they are no
longer referenced.

So chances are you don’t even need a SMOB ‘free’ function.

> However, why does the image example do this?

Indeed, the ‘mark’ and ‘free’ functions in that example could be removed
altogether, since the only resources associated with the SMOB is memory
returned by ‘scm_gc_malloc’.

Thanks,
Ludo’.

Re: smob gc protection, and inheritance

[Andrew Gaylard]

On 09/04/13 23:13, Ludovic Courtès wrote:
> Hi Doug,
>
> Doug Evans <dje@sebabeach.org> skribis:
>> 3) The docs aren't as clear as they could be on whether the "smob"
>> free function needs to scm_gc_free all results of calls to scm_gc_malloc
>> made when constructing the smob.  IIUC, this is not necessary.
> The ‘scm_gc_free’ function doesn’t need to be called nowadays, because
> the GC automatically frees ‘scm_gc_malloc’ regions when they are no
> longer referenced.
>
> So chances are you don’t even need a SMOB ‘free’ function.
>
>> However, why does the image example do this?
> Indeed, the ‘mark’ and ‘free’ functions in that example could be removed
> altogether, since the only resources associated with the SMOB is memory
> returned by ‘scm_gc_malloc’.
Hi Ludo',

Thanks for this information -- it helps answer my guile-dbi question
(http://lists.gnu.org/archive/html/guile-user/2013-08/msg00133.html).

You say "chances are" -- so when does one need a free() function?
I suspect that guile-dbi does require one, because it has to close
the DB handle; right?

Since the SMOB was allocated with scm_gc_malloc, and since the
things it mark()s are all SCM types, does it follow that it's safe not to
mark() it at all?

Where can I find more information about how guile and its GC work?
In particular, is there a FAQ guide to debugging GC problems?
I'm concerned about leaks, objects collected/freed too early, and
similar bugs.

BTW: all of this is in the context of guile-2.0.9.

Many thanks,

-- 
Andrew

Re: smob gc protection, and inheritance

[Ludovic Courtès]

Hi,

Andrew Gaylard <ag@computer.org> skribis:

> On 09/04/13 23:13, Ludovic Courtès wrote:
>> Hi Doug,
>>
>> Doug Evans <dje@sebabeach.org> skribis:
>>> 3) The docs aren't as clear as they could be on whether the "smob"
>>> free function needs to scm_gc_free all results of calls to scm_gc_malloc
>>> made when constructing the smob.  IIUC, this is not necessary.
>> The ‘scm_gc_free’ function doesn’t need to be called nowadays, because
>> the GC automatically frees ‘scm_gc_malloc’ regions when they are no
>> longer referenced.
>>
>> So chances are you don’t even need a SMOB ‘free’ function.
>>
>>> However, why does the image example do this?
>> Indeed, the ‘mark’ and ‘free’ functions in that example could be removed
>> altogether, since the only resources associated with the SMOB is memory
>> returned by ‘scm_gc_malloc’.
> Hi Ludo',
>
> Thanks for this information -- it helps answer my guile-dbi question
> (http://lists.gnu.org/archive/html/guile-user/2013-08/msg00133.html).
>
> You say "chances are" -- so when does one need a free() function?

When some of the resources associated with a SMOB are not under GC’s
control, and thus need to be freed explicitly by some other means.

Examples of such resources include malloc’d memory, file descriptors,
and opaque objects managed by an external library.

> I suspect that guile-dbi does require one, because it has to close
> the DB handle; right?

In the case of GDBM, for instance, ‘gdbm_open’ returns an opaque
GDBM_FILE, and that has to be explicitly freed via ‘gdbm_close’.  So
yes, in that case a SMOB ‘free’ function is required.

> Since the SMOB was allocated with scm_gc_malloc, and since the
> things it mark()s are all SCM types, does it follow that it's safe not to
> mark() it at all?

Yes.  Quoting the manual (info "(guile) Smobs"):

   Defining a marking procedure may sometimes be unnecessary because
   large parts of the process’ memory (with the exception of
   ‘scm_gc_malloc_pointerless’ regions, and ‘malloc’- or
   ‘scm_malloc’-allocated memory) are scanned for live pointers(1).

> Where can I find more information about how guile and its GC work?
> In particular, is there a FAQ guide to debugging GC problems?

The manual has some info under “Smobs” and “Memory Blocks”.  Guile’s GC
is the BDW-GC, whose documentation is available from
<http://www.hpl.hp.com/personal/Hans_Boehm/gc/>.

HTH,
Ludo’.

Re: smob gc protection, and inheritance

[Andy Wingo]

On Tue 03 Sep 2013 21:27, Doug Evans <dje@sebabeach.org> writes:

> 2) Is it possible to inherit, e.g., with goops, a smob?
> IOW, can I extend a smob through inheritance?
> Or must I store the smob in a class, and provide accessors?
> [kinda like the "is a" vs "has a" relationship]

You can't really inherit from a SMOB in GOOPS.  SMOB types have
corresponding GOOPS classes, but in a practical sense they can only be
used as specializers on methods; they aren't useful as constructors or
superclasses.  This is because GOOPS objects and SMOB objects have
different representations.

It's possible to do SMOB-like things in GOOPS but it is tricky and not
well documented.  Guile-GNOME does this; see
http://git.savannah.gnu.org/cgit/guile-gnome.git/tree/glib/gnome/gobject/gtype.scm
for more.

Lately what I have been doing is just using the FFI, and setting
finalizers on pointers as needed.

Regards,

Andy
-- 
http://wingolog.org/

Re: smob gc protection, and inheritance

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> Lately what I have been doing is just using the FFI, and setting
> finalizers on pointers as needed.

This is by far the most flexible approach.

Ludo’.