freenode/#clasp - IRC Chatlog
Search
14:27:35
drmeister
I hit a bit of a roadblock in image save/load with Boehm - it's still possible in MPS.
14:29:16
drmeister
The problem with Boehm is 1. I need to put data and code close together for RIP relative addressing 2. So I need to put literal vectors into GC managed memory along with lots of code 3. I want the GC to ignore the code - it contains no pointers and I expect it will slow things down 4. So with Boehm I need to write my own marking procedure.
14:30:55
drmeister
5. There's a comment in the boehm header file that appears to have huge implications for this - I don't know how to get around it. They say that the marking function should only mark about 100 bytes of pointers before returning. I have no idea how I do that with things like simple-vector. I need to investigate what ECL does in this case.
14:34:13
drmeister
"do it in smaller pieces"???? How would I save the how much marking work I've done for any particular object and then pick up later?
14:37:08
drmeister
I don't see how it can work - other than for objects that it doesn't handle everything is scanned conservatively.
14:42:11
drmeister
What I need is something where I can say "for this object - only scan up to this point".
14:45:36
drmeister
ECL marks fields of well defined objects in a simple way in its marking function - ECL doesn't worry about overflowing the mark stack because the well defined objects only have a few fields to mark.
14:46:02
drmeister
I'm assuming for the moment that when it doesn't handle an object that boehm marks the entire object conservatively.
14:46:57
drmeister
If Code_O objects had small literal vectors (not something I can guarantee) then I could handle them like a well defined object.
14:47:36
drmeister
I should check the size of literal vectors. They are unbounded and there is no easy way to bound them.
14:49:44
drmeister
I've emailed Ivan Maidanski - the maintainer of boehm to see if he can give me pointers on this. https://github.com/ivmai
14:50:30
drmeister
Could you check the log for the last 30 min? I posted some stuff that I'd love to have your input on.
14:55:23
karlosz
drmeister: i'm not too familiar with how boehm scanning works, but even though vectors are unbounded in size, the size is still stored in a known position in the object, so couldn't the marking procedure just use that? or is the problem that you'd need to write a custom procedure in that case to parse the objects?
14:56:51
drmeister
The problem is they say I can only do a certain amount of marking work and if I don't fully mark everything that I push the object back onto the marking stack.
14:57:12
drmeister
How do I keep track of how much marking work is done if the marking function returns after doing a certain amount of marking work.
14:57:44
drmeister
Or does it not return and it calls a function after doing a certain amount of marking and then it continues?
15:01:36
karlosz
well, since you're supplying the mark procedure, can't you can keep track of the marking work there?
15:02:08
Bike
the marking procedure you define is supposed to do only a small amount of work and is called rpeeatedly by boehm while it's marking
15:02:09
drmeister
jackdaniel: In the precise GC mode ECL doesn't appear to mark things like the contents of vectors or hash-tables. Where does that happen?
15:04:27
karlosz
hm, i guess otherwise you'd have to add a field to each object for the gc to keep track of the state
15:05:59
karlosz
the comment there also seems to suggest that it's not actually necessary to break it up into smaller chunks
15:07:44
karlosz
in which case only varyobj sized objects would need to keep track of how much marking has been done, assuming that does incur space overhead of some kind
15:10:14
jackdaniel
drmeister: I'm not looking very carefully at the code, but cl_object_mark_proc seems to mark the contents of vectors
15:10:41
jackdaniel
self.t contains vector data, so the array pointer is marked, similar with hash.data