freenode/#clasp - IRC Chatlog
Search
16:05:33
drmeister
https://stackoverflow.com/questions/65739437/how-do-i-keep-track-of-marking-work-in-my-own-mark-procedure-for-boehm-gc-and-wh
16:05:53
drmeister
Ivan, the maintainer wanted me to ask questions like that - let's see how well it works.
16:10:52
kpoeck
Bike or karlosz ; Could you commit yesterdays fix for ltvc_read_bignum or ltvc_write_bignum? You might only have changed that on BigMac
17:32:17
drmeister
jackdaniel: Do you know if it's guaranteed that each object that gets passed to a mark procedure MUST be valid? I'm getting obviously invalid objects passed to my mark procedure from boehm marking threads (not the main thread). These objects are not coming from my objects that I push to the mark stack.
17:47:05
drmeister
It has a header containing the stamp and some tag bits and is followed by a fully constructed object.
17:47:58
drmeister
When I turn on guards a big header gets added with a couple of guard words that are set to things like 0xFEEAFEEBDEADFEEF and 0xAAAAAAAAAAAAAAAA.
17:49:00
drmeister
I am assuming that only valid objects can get passed to a mark procedure unless something is seriously wrong.
17:49:37
frgo_
drmeister: Have you seen https://github.com/ivmai/bdwgc/blob/57b97be07c514fcc4b608b13768fd2bf637a5899/typd_mlc.c#L364 - I don't actually know what's going on there but the comment connects to the stackoverflow question for me.
17:49:49
beach
If stack scanning is conservative, the stack scanner has no way of knowing what is an object and what is not.
17:51:00
beach
Oops, my (admittedly small) family just announced that dinner is served. So I'm off for today.
17:57:05
drmeister
That leaves me with even more questions. They DO seem to be using 'env' to keep track of the work done.
18:02:55
frgo
You shouldn't have to. If you set GC_ext_descriptors[env].ed_continued to true the machinery is there. Now, I don't know how to do that as I haven't looked into clasp GC code for ages.
18:04:01
drmeister
I see the GC_ms_entry defined as an opaque pointer in gc_mark.h and the actual definition in gc_priv.h - so - there be dragons.
18:06:24
drmeister
Is that consistent with your thinking? Or am I missing something. The GC_ms_entry and GC_ext_descriptors are in gc_priv.h that leads me to think I shouldn't need to use them.
18:07:20
drmeister
On the other hand - the API may be incomplete because I'm messing with things that no sane person would mess with?
18:08:20
drmeister
I am a bit heartened to see that they use 'env' to keep track of work - I was about to add a field to the end of any container that stores pointers. Perhaps I don't need to.
18:10:58
drmeister
https://www.bountysource.com/issues/56317406-can-custom-mark-procedures-be-incremental
18:12:25
frgo
So there's an API for making a descriptor: https://github.com/ivmai/bdwgc/blob/master/include/gc_typed.h#L52
18:15:27
frgo
I say it again: Complete guesswork here from me. But given your amazing code reading capability I thought it worth throwing in.
18:17:43
drmeister
I mean it might be a good time to include <gc/private/gc_private.h> but - I have butterflies in my stomach.