On Oct 19, 2004, at 1:56 AM, Leopold Toetsch wrote:

Jeff Clites <[EMAIL PROTECTED]> wrote:
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:

Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.

True, and some eval-segments are "done" as soon as they run (eval "3 +
4"), whereas others may result in code which needs to stay around (eval
"sub {....}"), and even in the latter case not _all_ of the code
generated in the eval would need to stay around. It seems that it may
be hard to determine what can be recycled, and when.

Well, not really. As long as you have a reference to the code piece, it's alive.

Yes, that's what I meant. In the case of:

        $sum = eval "3 + 4";

you don't have any such reference. In the case of:

        $sub = eval "sub { return 7 }";

you do. In the case of:

        $sub = eval "3 + 4; sub { return 7 }";

you've got a reference to the sub still, but the "3 + 4" code is no longer reachable, so wouldn't need to stay around.

But it's possible that Parrot won't be able to tell the difference, and will have to keep around more than is necessary.

And we have to protect the packfile dictionary with mutexes, when this
managing structure changes i.e. when new segments gets chained into
this list or when they get destroyed.

Yes, though it's not clear to me if all eval-segments will need to go
into a globally-accessible dictionary. (e.g., it seems the "3 + 4" case
above would not.)

It probably depends on the generated code. If this code creates globals (e.g. Sub PMCs) it ought to stay around.

Yes, that's what I meant by not all--some yes, some no.

JEff



Reply via email to