freenode/#clasp - IRC Chatlog
Search
16:30:52
Bike
right now we're actually leaving svref and aref and stuff as function calls, so no generated code problems there i guess
16:31:15
drmeister
So we will have the heap full of objects that contain GC pointers at certain offsets and a stack full of objects that contain GC pointers at certain offsets.
16:32:47
Bike
oh, this is a stupid question, but the whole idea with yieldpoints is that the GC will only run at yielddpoints we define, right? not anywhere
16:32:47
drmeister
If we can rely on just the GC managed pointers that we know about to keep everything alive and we pin the objects that are pointed to by the GC managed pointers on the stack - then I think we are doing better than boehm or MPS right now.
16:33:04
Bike
seems like it would be bad if the gc started and we're in the middle of __cxa_throw or something and god knows what's in any register
16:34:55
drmeister
We could NOT put them in C++ code at all in general and add them only at specific points - like MAP
16:35:54
drmeister
If we use patchpoints we can know where they all are and add and replace them with NOP dynamically.
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.