On Sunday 24 February 2008 16:55:48 Bob Rogers wrote: > Some of our memory problems seem to be strange interactions between > PObjs allocated out of constant pools, garbage collection, and > freezing/thawing PBC (not to mention the interaction of HLLs). > > Amen! -- particularly the "strange" part. I suspect that Kea-CL has > been hard hit lately because it may do things differently. Is there > something I should be looking out for?
The use of things freed inappropriately -- PMCs with vtable pointers of 0xdeadbeef or STRINGs where strstart and bufstart point into deallocated memory. > Why do constant PMCs ever need to point to non-constant ones? In other > words, why are those pointed-to PObjs not also constant? The reason is practical. PMCs have headers and bodies. When we create a PMC, we first create a header. This header can come from a constant pool or a non-constant pool. With the header, we initialize the PMC. The PMC may contain other PMCs. For example, a String PMC contains a STRING. Thus the initializer itself might allocate new PMCs. There's no way of telling, in a static sense, whether a given PMC will be constant. Thus the initializers don't check the constantness of the PMC when allocating contained PObjs. They *could*, but if that were the case, we'd need twice the code in our initializers to build PMCs that only contained constant information -- check a flag and then decide which way to allocate any new PMCs. (There could also be cleverness with pointers or swapped vtables or what-have-you, but it introduces extra complexity.) There's a similar problem for accessors and setters. Again, that's solveable with more code or more cleverness. However, it's difficult to determine at the point of allocating a header whether any given PObj is going to end up contained within a constant PMC somewhere... so we'd have to perform this check on every operation that could possibly store a PObj in a constant PMC. That's doable, with plenty of code or cleverness. However, some of those PObjs might have active references pointing to them from elsewhere, so silently upgrading them to constant PObjs (that is, allocating a new constant header and then copying everything to that new header) requires fixing up all of the old references. That's fixable, but I usually have to go lie down after thinking about it. > IIUC, this is > different from any GC system that I've ever heard of. The whole point > of having "pure space" (or whatever you want to call the readonly > constant space) is to avoid having to follow pointers into pure space; > this ought to be unnecessary because pure objects can't keep dynamic > space objects live. If you allow pointers from pure space into the rest > of the heap, then that invariant no longer applies, and you are forced > to trace pure objects just like any other. Am I missing something here? Hysterical raisins, mostly. This would be easier with a redirection scheme or stricter rules on assignment and such. > I wish I understood even a tenth part of Parrot's memory management. > Given that handicap, I'd be happy to help, in whatever way I can, but > I'm afraid it will take a while to get me up to speed. docs/dev/ has some good information, but the best way to understand it further is to debug it for a while. Sadly, I think I've fixed many of the easier bugs. -- c
