Re: [RFC] multiple code segments and the interpreter
by Leopold Toetsch other posts by this author
Jan 30 2003 7:42AM messages near this date
Re: [RFC] multiple code segments and the interpreter
|
Re: [RFC] multiple code segments and the interpreter
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
Thread:
Leopold Toetsch
Leopold Toetsch
Leopold Toetsch
Nicholas Clark
Nicholas Clark
|