Re: GC and simple smobs??

[Jean Abou Samra]

Le 17/06/2022 à 23:46, David Kastrup a écrit :
> Nope.  They are on the stack.  They may either be immediate SCM values
> with nothing on the heap (like SCM_EOL or small integers), or they may
> point to a heap cell.  In that case, scanning the stack during GC will
> pick up the SCM values and mark the associated cells in the heap.



Well, OK, they are small stack values each storing a pointer to
a heap object. Right?



> > The unsmobbed a and b are thus pointers to data on the BDWGC heap.
> Correct.
> > Since they are pointers to the part of the SCM that stores the C++
> > object, and not to the start of the SCM value, they won't cause the
> > SCM to be marked by their mere existence on the stack.
> Correct.
>
> > p1 and p2 are not used after the LY_ASSERT_SMOB calls. The compiler
> > could drop them before the end of the function.
> Unlikely since that would mess up the stack frame, but let's assume so.
>
> > In that case, nothing protects p1 and p2 between the two LY_ASSERT_SMOB
> > lines and the Duration::compare. If the ly:duration<? call is a tail
> > call, Guile itself might not hold references to the duration objects.
> > If that happens, a crash would ensue.
> Why?  There is no allocation happening anywhere, so there is no reason
> to do garbage collection.  At least I think that is the rationale also
> covering a lot of Guile-internal code.


If I understand you correctly, this code doesn't need it, but it
would if there were a call to scm_something () between LY_ASSERT_SMOBbing
and the call to Duration::compare?

I thought you said it was unclear whether BDWGC could run outside
of Guile allocations, but if it doesn't, I am happy.



> > This pattern looks somewhat frequent, so I hope I am wrong. If so,
> > where is my mistake?
> Hopefully above.


Thanks for replying.

Jean