In #8930 I fixed an issue where eval scopes that JIT would fail to provide the eval with an appropriate backtrace frame. Because the JIT does not push backtrace frames, any eval-containing frames that JIT would from then on provide an incorrect frame to use for __FILE__ reporting. The fix for that was to use our full JIT-aware backtrace construction to provide a true backtrace frame before entering the eval. The side effect of this is that eval calls will all now require some amount of JVM stack trace reification (albeit lazily using the StackWalker API).
We could handle such eval calls from JIT by defining special logic in the call site that knows how to set up eval with the caller's filename and line number already in-hand. This would eliminate the need for either an interpreter frame or heavy backtrace construction by routing around the generic eval logic that has to work for both interpreter and JIT.
It remains to be seen if the overhead of the JVM stack trace version will be a real-world problem for most code; eval should be seen rarely, usually at boot when things are slow and interpreted anyway, and it is itself rather slow and heavy.
In #8930 I fixed an issue where eval scopes that JIT would fail to provide the eval with an appropriate backtrace frame. Because the JIT does not push backtrace frames, any eval-containing frames that JIT would from then on provide an incorrect frame to use for
__FILE__reporting. The fix for that was to use our full JIT-aware backtrace construction to provide a true backtrace frame before entering the eval. The side effect of this is that eval calls will all now require some amount of JVM stack trace reification (albeit lazily using the StackWalker API).We could handle such eval calls from JIT by defining special logic in the call site that knows how to set up eval with the caller's filename and line number already in-hand. This would eliminate the need for either an interpreter frame or heavy backtrace construction by routing around the generic eval logic that has to work for both interpreter and JIT.
It remains to be seen if the overhead of the JVM stack trace version will be a real-world problem for most code; eval should be seen rarely, usually at boot when things are slow and interpreted anyway, and it is itself rather slow and heavy.