The summary reminded me I had a question still
On Thu, Jan 30, 2003 at 08:42:34AM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> >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.
How do you know if they are there? Presumably the constant table is just
an array. It may start ordered, but if you can add values to it, it becomes
unordered. How is eval going to determine if a constant is already there?
Create a hash table of values present at the time of the first eval, and
use that from then on?
That feels expensive, as does the only alternative I can think of (linear
search). Whereas simply creating new constant tables each time feels
cheaper, albeit with more transient cost in memory, but less long term
if they can be freed before parrot's exit.
>
> >... 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.
I can't see a good way to tell the second two apart. ("hindsight" isn't
a good way, until someone starts making computers than can travel both
directions in time)
What's the relative cost in calculating constants, versus adding them to
a table? I'd've thought that most of the effort would actually go into
working out what the value is, with only a little more for "have we seen
this before". Hence is all this discussion about constant tables (making
lots with lots of GC, or making few but having to keep track of things)
false optimisation?
> >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 ;-)
Normal. The other two types of block always refer back to a normal block,
don't they?
Nicholas Clark
