in reply to Re: How does CATCH_SET optimize efficiency?
in thread How does CATCH_SET optimize efficiency?

For example in the following: 
sub FETCH {
    for (1..3) {
        eval { $x }
    }
}

sub TIEARRAY { bless [] }

my @a;
tie @a, 'main';
$y = $a[0];

[download]
When the tie FETCH method is called, je_mustcatch is set to true, so the first time pp_entertry is called, it pushes a new jump level and enters a new runops loop. The second and third time pp_entertry is called, je_mustcatch is false, so the try block is executed within the current (inner) runops loop.

Dave.

Replies are listed 'Best First'.
Re^3: How does CATCH_SET optimize efficiency?
by PerlOnTheWay (Monk) on Dec 16, 2012 at 14:06 UTC

    Dave, thanks for your reply. But I've still got several questions:

    1. when is je_mustcatch set back to false?

    2. so the way it optimizes performance is by reusing the same jump level for multiple times?

[reply]
      One way of looking at it is that a naive implementation would have have every eval, require, try etc push a new jumplevel and enter a new runops loop. That way, when an exception occurs and a longjump occurs, the inner runops loop execution is popped of the C stack, and control returns to pp_entertry or whereever, which can then handle the exception how it wants.

      An optimisation to this is to have a flag (je_mustcatch) that can be set to indicate that the caller of the current runops loop can catch longjumps, handle the exception, and if necessary restart a new runops loop. In this case, there's no need to push a new jumplevel and runops loop each time.

      The top-level execution of a perl program consists of setting up a jump level and entering a runops loop, so it sets je_mustcatch to false there: the top-level is already set up to handle expections.

      Whenever perl code is called "from C" rather than directly from perl, such as FETCHes, overload code, or perl code called from XS, then it creates a new runops loop, but in this case the loop isn't protected by a new jumplevel and expection handler. So the caller of FETCH sets je_mustcatch to true, to notify any potential eval ops that they should set up their own handler.

      So the net effect is that in practice, eval {} almost never has to push a new jump level and runops.

      Dave.

[reply]

        But FETCH is always called "from C", so the je_mustcatch is always true, and the eval ops will always create a new runops loop.

        Why not set up a new runops loop directly in the first place?

[reply]

In Section Seekers of Perl Wisdom