Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Tue, 21 Oct 2003, Leopold Toetsch wrote:
[ thaw ] >> This should IMHO be able to create constant PMCs out of metadata, e.g. >> for subroutine objects. So there should be some means to tell thaw() to >> create PMC(s) in the constant_pmc_pool. > There should be a way to put PMCs in the constant pool in general. I was > thinking a constant op would work--something like > constant Ix, [SP]y > to make the string or PMC Y a constant at slot X in the constant pool. You can append items to the constant table. You can't declare existing items as constant, because you can't change the underlying object pool, where the object was allocated. This would change the objects address. > Passing in the PMC header to be filled in also works, though both fail if > you want full PMC trees marked as constants since thawing out a PMC stream > may involve creating multiple PMCs. (In which case we might be better > temporarily switching allocation pools at constant creation time, rather > than passing in PMCs) These are either serious shortcomings or unneeded workarounds. An extra parameter to relevant vtables can take care of such special cases. >> I dunno, why chill() is superior to dump() or pretty_print(), but the >> name doesn't really matter. > The important thing is that it's not a vtable method. Ah, that's the difference. How shall the system pretty-print dynamically loaded PMCs then, when only a bytecode-stream is available? IMHO only a vtable in the class can perform that job. >> > 1) Freezing at the destruction level may *not* use any additional memory >> > for object traversal > It puts a number of unpleasant constraints on the core freeze routines. Constructing the frozen stream definitely needs memory. I don't see the difference, to memory consumed by a seen hash. Can you please elaborate a bit more on this. > The only thing that mark does that the general traversal doesn't, in the > abstract, is flip the object's live flag. Everything else is an > optimization of code which we can, if we need, discard. Yes, mark() can be written in terms of a general traverse, which gets a vtable function (and a data pointer). mark is basically traverse(mark, 0). But this isn't true the other way round. You can't do freeze based on the mark iterator. How do you pass the desired output format? >> mark() is called permanently in a running interpreter, that does non >> trivial things. There are shortcuts for scalars, DOD is highly optimized >> not to destroy cache coherency. Using mark() also implies to back out >> my small PMC patches. All the advantages of smaller scalars are gone >> then. > All of this stuff for freezing is going to end up killing the small PMC > patch anyway, unfortunately, since we're going to have to be able to > traverse PMCs in the destruction phase, which means we have to have the > means of traversal at hand as we can't guarantee that we can allocate more > PMCs or resize the PMCs ext data. A scalar can't contain or reference other PMCs, so it can't be a potential source of freeze loops. If I now spit out (PMC: Int, ID=xy, value=5) twice or (PMC: ID=other) doesn't really matter. thaw() can take care of duplicates, if needed. Other PMCs have the next_for_GC pointer. Albeit I'm not convinced, that we can't have a seen hash. > YHO, in this case, turns out to not consider all the issues involved. That might very well be true, yes. So it would be fine, if you could fill the gaps. > Dan leo
