Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Tue, 21 Oct 2003, Leopold Toetsch wrote:
>> 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. > The object's address should be irrelevant for the constant table. PMCs are > referenced in the opstream by table offset. Only in the opstream. But not when such PMCs are used then. I.e. when constant Sub PMC is refered to in the global stash. >> 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. > If the dynamically loaded PMC class doesn't have a backing Parrot class, > you can't, and get the default, relatively primitive dump. I was thinking of plain PMCs, that where loaded to provide some special functionality. Parrot doesn't know anything about these, so will be unable to pretty print the opstream. Loaded classes OTOH as based on ParrotClass and should be printable. >> 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. > Constructing the frozen stream will need some memory, yes. At the moment > all it needs is a chunk of random memory and that's it, so we may well > fail because we're out of memory. So, with the same argument I can say, (destructor level) freezing will need *system* memory for the stream plus the hash. So we may well fail. I don't see any difference. The hash hasn't to be a "fat" PerlHash. If we don't want a hash one bit inside the objects arena flags should be able to serve the same functionality - this PMC already got serialized. Anyway - how does/would freezing at destructor level look like from HLL POV? Shortly before, there ought to be a full DOD run (or all possible garbage would be frozen). At this time, the amount of still active and then to be serialized PMCs is known (an upper boundary is always known). So it should be possible to work around such constraints. > ... We may, however, have general pool > memory handy. We can't guarantee that we have *any* headers, however, > since we can legitimately be called from within the destruct phase of a > DOD run, which may have been triggered by an out-of-headers condition. I really doubt, that thawing a program (or some data of it), that died in middle of some non trivial operation, because it ran out of headers, will be of any use. >> 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. > Thaw can only properly take care of duplicates if the duplicates are > correctly indicated in the serialization stream. Identical end-values are > *not* sufficient to note multiple references to the same PMC. Sorry I thought of PMC IDs, which are the address of the frozen PMCs. >> Albeit I'm not convinced, that we can't have a seen hash. > It takes an insane amount of memory and requires header allocation. A PerlHash takes more memory, and yes. But we just need a hash of PMC addresses, or a bit inside the objects arena. We have several different traverse-like functions: * mark (DOD): called frequently, should get all possible speed * freeze (destruction): no speed issues, can't take Parrot resources * freeze (user): rarely used, can take resources * destruction ordering: only active objects to be visited * clone: can take resources thaw(freeze()), or separate vtable * dump/pretty-print: no vtable? * thaw: special class method, is different anyway The first 2 critical items have diametral usage patterns. This does not really imply, that they should be implemented based on the same scheme. > ... We > can't allocate headers, and the memory requirements are extreme. Been > there, done that, it was a bad idea. Consider this arbitrarily and > unconditionally ruled out if you're unwilling to believe the stats that > were previously posted about this. You are speaking of Storable.pm? I'm not aware of any stats regarding that. But I'm not thinking of using a full fledged hash for such a special case. > Dan leo
