Nicholas Clark wrote:
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?
Yep. The value in length of op's comes out for free by reading the packfile. The length in bytes is not needed at all (AFAIK).
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.
... only if they are not yet there.
... 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.
Normally constants are folded. I think, there are 2 or 3 kinds of code to be evaled:
- code is static - need to be compiled only once
- code changes but constants are the same
- all dynamic
The latter would need a constant_table per eval/code_block, which then get's recycled. But as it seems not too easy to detect, if an evaled code in a loop does produces always the same constants, it might be necessary to always regenerated (and GC) the constant table too.
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.
Do you like to append the constants to the "normal" code block, to the prederefed or to the JITed ;-)
Nicholas Clark
leo
