freenode/#clasp - IRC Chatlog
Search
16:46:09
cracauer
No yield points at all in C++ code can backfire. It could delay GC while stalling all other threads.
16:47:41
cracauer
I think internal pointers into cons cells are the only easy ones. If cons cells live in a separate space. You can always find the beginning of the object via alignment.
16:56:11
drmeister
I think that's the data structure that the boehm GC uses to identify base pointers.
16:58:36
drmeister
I would be tempted to say "what - that old thing?" but boehmgc is surprisingly efficient.
16:59:22
drmeister
What I'd like to move to is where we implement the stack scanner so we can run it in a "safe" mode and a "precise" mode.
17:01:04
drmeister
Safe mode would scan conservatively and use a data structure like what is above and look for conservative pointers that point to objects that aren't backed by a precise pointer in the same stack frame.
17:03:52
drmeister
It would just be C++ code - we can make all Common Lisp code safe by changing the generated code.
17:04:44
Bike
i've been reading a bunch of papers about memory models in the last few days and apparently hans boehm is pretty involved in the C++ standardization process about it. surprised me a little.
17:05:32
Bike
if we didn't have any yield points in C++, then besides what martin said, couldn't we actually run out of memory if they allocate lisp objects? because there'd be no gc running
17:06:09
drmeister
Yes. Functions that run for a long time and do lots of allocation with no yieldpoints would blow up.
17:07:21
drmeister
Oh wait - if you call a function with yield points then the callee needs to have its stack frame be consistent.
23:33:14
drmeister
::notify frgo Could you describe the crash that you experience building quicklisp with clasp on BigSur? I cleared my quicklisp cache and loaded iclasp-boehm and used (load "~/quicklisp/setup.lisp") and it worked.
23:37:28
drmeister
::notify frgo Could you give me the particular quicklisp systems that you were trying to build?
23:51:31
drmeister
Ironclad with alexandria and bordeaux-threads takes 212 seconds - this is on a macbook air 1.1 GHz Quad-Core Intel Core i5
23:54:29
drmeister
::notify frgo Don't use cclasp-boehm - use iclasp-boehm. cclasp-boehm won't work for a few more months until we upgrade to llvm12. Otherwise I don't see what you are doing that would crash. Ping me when you get this and I'll dig deeper.
0:52:06
kpoeck
drmeister frgo was calling cclasp-boehm and still compiling quicklisp, see https://gist.github.com/dg1sbg/afb4c951bcdd1a8e1e3eaeb9ec549450
1:19:11
drmeister
Ah - my memory is all jumbled up. cclasp-boehm is a symbolic link for iclasp-boehm
1:20:54
drmeister
I think there must be something different about frgo's environment relative to mine that is breaking his clasp. Mine just built and builds quicklisp and ironclad with no problems.
1:21:38
drmeister
It used to be (and will be again) that cclasp-boehm links together all of the Common Lisp and C++ code into one executable.
1:22:14
drmeister
iclasp-boehm is just the C++ code and it loads a an image file that is a big faso file.