Re: Java finalization & smobs?

2021-12-10 Thread Maxime Devos
Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]:
> We can change our mark routines to avoid the crash, but it's unclear
> to us if this behavior is intended or not, and we worry that this
> will
> come back to bite us in the future.
> [...]
> [... things about Java-style finalisation ...]

Keep in mind that Jonas Hahnfeld (from LilyPond) was looking into _not_
enabling Java-style finalisation (until guardians are used), see
.

Greetings,
Maxime




Re: Java finalization & smobs?

2021-12-10 Thread Maxime Devos
Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]:
> On the one hand, the docs for smobs state "must assume .. all SCM
> values that it references have already been freed and are thus
> invalid", which suggests that smob freeing happens in random order,
> which is consistent with what we see. On the other hand, Guile sets
> up
> BDWGC with GC_java_finalization=1, which should keep GC dependencies
> of an object alive until the object itself is finalized, and I think
> we have observed the mark calls that make this happen.
> 
> which of the two is it?

I assume that the fact that Java-style finalization is used, is
considered an internal implementation detail.

That doesn't explain why things are going wrong, of course.

Greetings,
Maxime




Re: Java finalization & smobs?

2021-12-10 Thread Maxime Devos
Hi,

Han-Wen Nienhuys schreef op vr 10-12-2021 om 15:59 [+0100]:
> which is consistent with what we see. On the other hand, Guile sets
> up
> BDWGC with GC_java_finalization=1, which should keep GC dependencies

At least in Guile 3, that's done in scm_init_guardians.
While that's always called in scm_i_init_guile, maybe Guile 2 only
loads the guardian code when it's really needed and doesn't set up
Java-style finalisation?

Greetings,
Maxime (not a guile maintainer).




Java finalization & smobs?

2021-12-10 Thread Han-Wen Nienhuys
Hi Guile devs,

We are debugging a GC issue in LilyPond when used with Guile 2.2, and
could use some help.

The issue and associated Merge Request are here:

https://gitlab.com/lilypond/lilypond/-/issues/6218
https://gitlab.com/lilypond/lilypond/-/merge_requests/1035

We are using smobs with custom mark and free functions for
interfacing with our C++ code. We are seeing that sometimes mark
functions are called on smobs which have their dependencies already
collected, leading to crashes.

We can change our mark routines to avoid the crash, but it's unclear
to us if this behavior is intended or not, and we worry that this will
come back to bite us in the future.

On the one hand, the docs for smobs state "must assume .. all SCM
values that it references have already been freed and are thus
invalid", which suggests that smob freeing happens in random order,
which is consistent with what we see. On the other hand, Guile sets up
BDWGC with GC_java_finalization=1, which should keep GC dependencies
of an object alive until the object itself is finalized, and I think
we have observed the mark calls that make this happen.

which of the two is it?

(I am seeing the problem on Fedora 35, with Guile 2.2.7 and libgc 8.0.4)

--
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen