freenode/#clasp - IRC Chatlog
Search
3:59:19
drmeister
I've been slowly working on the GCing of code. I just kicked the supports out from under the code and ObjectFile_O objects are being garbage collected but Code_O objects are not.
3:59:52
drmeister
Something is holding on to them - I'll have to write a tool to track ownership of objects back to roots.
4:00:18
Bike
hm, could it be other code? but i suppose they shouldn't be referring to each other directly
4:03:22
drmeister
It's also surprising how fast the system is. I expected it to get bogged down with all the code it has to slog through - but I don't notice any slowdown at all.
4:04:42
drmeister
I have a function (llvm-sys:release-object-files) - it zeros the linked list of object files.
4:04:58
drmeister
Then I do a GC and there is a cascade of object files that get finalized - but no code objects.
4:07:22
drmeister
ObjectFile_O objects point at Code_O objects. The Code_O objects are new - and nothing else should know about them let alone point to them.
4:08:13
drmeister
Oh wait ObjectFile_O objects have other raw pointers that I may be pointing at Code_O objects.
4:09:36
drmeister
If I clear the linked list of ObjectFile_O objects the ones that were being kept alive get collected.
4:10:00
drmeister
But their memory remains full of pointers to the Code_O objects so they remain alive.
4:10:22
drmeister
Until the old memory for ObjectFile_O gets overwritten the Code_O objects would remain.
4:38:32
Bike
let's see, we make irbuilders in... landing-pad, cmprunall, compintrinsics, cmpir, cmpeh, translate, arguments, codegen-special-form...
4:43:43
drmeister
It was the pointers in an ObjectFile_O - I removed them all except one Code_O pointer - and I zero that out in the ObjectFile_O dtor.
4:45:06
drmeister
Still there should be a 1:1 correspondence between ObjectFile_O collection and Code_O collection.
4:47:03
drmeister
This is with boehm. The interesting thing is that it should be safe to GC code all the time. Return addresses on the stack are interior pointers and should keep code alive.
4:47:48
drmeister
This isn't the case with MPS - it doesn't support interior pointers for non-moving objects.
4:56:37
drmeister
Something is up. A few Code_O objects are being collected - but not nearly enough.
4:57:25
drmeister
I know - I'll track what Code_O objects are associated with what ObjectFile_O objects
5:06:36
drmeister
Perhaps I am not holding on to enough ObjectFile_O objects. My Code_O objects weren't pointing to their ObjectFile_O objects.
5:07:02
drmeister
Code_O objects are also kept alive by FunctionDescription_O objects because entry points are interior pointers.
5:09:26
drmeister
Ok - that leads to the next problem. What the eff is holding on to all the llvm objects?