Jean Abou Samra <j...@abou-samra.fr> writes: > 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?
Yup. Not a pointer in the C meaning but a pointer in the SCM-encoded manner. >> 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? Yes. In this case it might make more sense not to store pointers but actual durations, like Duration d1 = *LY_ASSERT_SMOB (...); > I thought you said it was unclear whether BDWGC could run outside of > Guile allocations, but if it doesn't, I am happy. I have no idea. It is somewhat troubling that Guile2 is a lot more prone to trigger GC problems than Guile1. -- David Kastrup