On Wed, Jan 29, 2003 at 02:12:01PM +0100, Leopold Toetsch wrote: > The variable layout of interpreter->code (actually the packfile) doesn't > fit very good for multiple code segments. There is only one ->byte_code > pointer, the byte_code_size is in bytes and converted zig times into > opcode_t's and so on.
Would it be better to store the value as a length in opcode_t's, and convert back to bytes where needed? > > so: > > 1) rename interpreter->code to interpreter->pf (the packfile) > > The packfile owns all PBC segments: byte_code, const_table and so on. > These segments are all organized in the directory segment. Eval'ing code > generates a new code segment and appends constants to the const_table, > so far so good: But how to load a precompiled PBC module whith its own > const_table (with constants numbered from 0 and spread all over the > code). So: > > 2) we need multiple constant_tables too. > > As one or more code segments may refer to these constants, they > constant_table must be linked to these code segments. > > 3) one PBC file has exactly one const_table (or none if no constants are > used) and may have multiple code segments If I understand you correctly, every time an eval happens, more code is created, and that code's associated constants are appended to the constant table. As is, this feels like an effective leak - in a long running process (eg mod_parrot) there is the potential for something to cause repeated evals, where the code is used only once then discarded. The parrot code block can be released, GCed and recycled, but the constant table will keep growing. Maybe code blocks should keep their own constants, so that they can be released together. Maybe they should even be in the same bit of allocated memory, so that locality helps caching and VM performance. Nicholas Clark
