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
