Jonas Hahnfeld <[email protected]> writes: > Am Dienstag, den 05.05.2020, 17:09 +0200 schrieb David Kastrup: >> I am currently digging back and forth regarding implementation of our >> Smobs (Scheme objects) and garbage collection and STL, and I think I am >> converging on the realisation that we'll have to end up duplicating >> those parts of STL that we are using. > > Please forgive my ignorance, but I'm missing a bit of context. Are we > talking about vector/lists/... of Smobs? Or is the issue that Smobs > contain STL containers?
Vectors/lists of Smobs are inherently not protected from garbage protection even when in "auto" stack space or other GC-scanned space (Guile-2 has different options there). That's a problem. One important GC-scanned space that we'd ultimately want to automate scanning of are Smobs. STL containers cannot be automatically scanned even when they are formally located in scanned memory. > In any case I'm not really fond of duplicating code. Given that it > seems to "work" right now, IMHO this needs to give some very clear > advantage over keeping the status quo. GC performance remains a major troublesome point. I want to get the point to where we don't need mark hooks, and where we don't need finalisation hooks. Either are causing performance problems, and with Guile2, they also have a history of causing stability problems as well as "nobody wants to do that, so we are not really interested in your problems" reactions from Guile developers. What I was writing about is to reduce the amount of code duplication by not considering use of STL as free for the taking (which might cause more and more need for reimplementation of stuff). I do not see that at the current point of time regarding both code bases and standards (reflection is not in current C++ standards though it may appear at some point of time) we have a reasonable chance to make STL free for the taking. The underlying dynamic allocation and destruction model is not really a perfect match to what Scheme does and expects, and what the garbage collectors we are dealing with are good at. But I am not arguing API duplication: there is a point in making the semantics of SCM-aware reimplementations follow STL Container semantics. That will allow us at one point in the future when the SCM memory model is a better match to STL allocators, to go back to STL. But the different lifetime models will always mean that we are pressing our luck when using STL under the assumption that running destructors is optional. I might still try coming up with some reflection engine that would work with STL without significant performance impact and some reliability, but I would not expect it to come cost free. -- David Kastrup
