freenode/#clasp - IRC Chatlog
Search
10:38:06
no-defun-allowed
scala-native has a "Commix" which is supposed to be concurrent, but I can't find information on it.
10:40:23
no-defun-allowed
Well, here it is, I don't know how portable it is though: https://github.com/scala-native/scala-native/tree/master/nativelib/src/main/resources/scala-native/gc/commix
11:09:11
no-defun-allowed
https://github.com/scala-native/scala-native/pull/1423 tells us that it has parallel but stopping-the-world marking, and concurrent and parallel sweeping. Otherwise I would have said something like "Hey, that would be interesting to compare to mark-sweep, for the SICL global heap!"
11:12:54
no-defun-allowed
Well, no, it sometimes evacuates regions, which is a big change, and it might be why marking isn't concurrent (as evacuation is performed "opportunistically" while marking).
16:51:14
drmeister
clasp keeps crashing when start using multiple threads with the boehmprecise mode.
16:51:41
drmeister
I put a mutex in the mark procedure I added (which works single threaded) but that doesn't help.
16:52:07
drmeister
We compiled up a version of boehm with debug info - I'll link that in an see if I can figure out what is going wrong.
20:26:06
drmeister
Check what xcode you have it may have been updated. I just started it up and it says 12.3 and asked me to install components.
20:32:43
drmeister
I'd be surprised that that is the problem. boost hasn't given us problems for a long time.
20:36:11
cracauer
fixed. The problem was that boost 1.60 seemed to have partially conflicted with 1.75. Reinstall of 1.75 fixed it.
21:21:14
drmeister
I'm trying to get clasp in the new boehmprecise mode to work with compile-file-parallel.
21:22:42
drmeister
But when I invoke compile-file-parallel every thread gets stopped by a signal 24.
21:23:20
drmeister
That's SIGXCPU - this looks like boehm is sending the signal to stop all the threads for GC - which would be regular maintenance/normal operation.
21:30:07
frgo
I am now online. Hello. And yes, SIGXCPU is used as the thread restart signal. See https://github.com/ivmai/bdwgc/blob/57b97be07c514fcc4b608b13768fd2bf637a5899/pthread_stop_world.c#L376
21:31:57
drmeister
frgo: We've made a lot of progress. I have a clasp running with boehmprecise mode
21:32:38
drmeister
But compile-file-parallel doesn't work and it looks like clasp is responding poorly to the SIGXCPU signal that boehm sends to all threads to suspend them for GC.
21:33:02
drmeister
"responding poorly" = treating it like an error and bringing up the clasp debugger.
21:34:10
frgo
boehmgc does handle this specially. See https://github.com/ivmai/bdwgc/blob/57b97be07c514fcc4b608b13768fd2bf637a5899/pthread_stop_world.c#L356
21:34:53
frgo
Hm - yes, don't know. I haven't been following any code changes in boehmgc, if there are any.
21:36:35
drmeister
I haven't made any changes to boehmprecise that deals with signals relative to boehm.
21:37:01
drmeister
To be clear. clasp "boehm" mode means the boehm version of clasp that we all know and love.
21:37:44
drmeister
clasp "boehmprecise" mode is a new boehm mode for clasp that uses the offsets of pointers from the static analyzer to scan a subset of pointers in objects - it makes boehm precise on the heap and it remains conservative on the stack.
21:38:14
drmeister
No - I'm working in the "precise" brach of clasp. I need to push some stuff. Do you want the latest "precise" branch?
21:38:42
drmeister
It's easy to use. You set USE_COMPILE_FILE_PARALLEL = False in wscript.config and use:
21:44:05
drmeister
No need - I will build on macOS to make sure that it works - but you can proceed as well - it should build.
21:44:24
drmeister
I'll paste a wscript.config that I am using for debugging so you can replicate my system
21:54:38
drmeister
I am running iclasp-boehm and invoking compile-file-parallel from inside of the udb (gdb with timetraveling) debugger.
21:55:32
drmeister
This iclasp-boehm is exactly the same code as iclasp-boehmprecise - the iclasp-boehm is just using boehm in the conservative mode
22:00:52
drmeister
If I do this in iclasp-boehmprecise and catch the SIGXCPU - the backtrace looks the same - but then I STOP handling the SIGXCPU and continue and the clasp debugger starts up.
22:03:10
drmeister
It looks like in both cases it goes in to GI___sigsuspend in both cases but when it proceeds with iclasp-boehmprecise, clasp reacts like there was an error and starts up the debugger.
22:03:49
drmeister
I don't know what happens with iclasp-boehm - perhaps I can single step and follow the execution from the point of catching the signal.
22:06:58
drmeister
To support boehmprecise mode (and all the GC modes) I now have the CPP flags set up like this...
22:10:23
drmeister
The conservative/old/regular mode of boehm has USE_BOEHM defined and NOT defined USE_PRECISE_GC
22:10:47
drmeister
I don't believe that I changed how boehm is initialized when USE_PRECISE_GC - checking...
22:13:29
drmeister
As far as I see - the only thing I do for boehmprecise mode is define new boehm 'kinds' and mark procedures.
22:13:58
drmeister
Also, when I allocate objects with boehm - I call functions that I pass the object 'kind' to.
22:16:43
drmeister
frgo: FYI - I'm using the Undo debugger - it's a time-traveling debugger that lets me step backwards. It's very handy.
22:18:21
frgo
Yeah - no worries. I need to completely setup my clasp build env from scratch. So that takes some time...
22:18:49
drmeister
I'm currently running iclasp-boehm, telling udb to 'handle SIGXCPU stop" and then I'll step forward and see what the normal behavior should be.
22:20:13
drmeister
The other thing we have done is compiled boehm with debug flags and we link it in to clasp so we can see the source code.
22:27:35
frgo
drmeister: Could you email me your wscript.config file? => frank.goenninger@goenninger.net