I have a JIT I've been working on for a few days now, and initial results were awesome, the JIT log showed just a few assembly ops to execute each iteration of a simple "count to 10000" loop. However, then I changed something and the traces stopped being generated. I hooked up the JIT hooks and noticed that about every 1000 iterations I'd get "ABORT_ESCAPE". After a bit more printing I get this: https://gist.githubusercontent.com/halgari/3cd3cd10f359f2103b89/raw/d8f335f7... Now if I disable virtualizables, everything works fine. What should I be looking for to troubleshoot this? Thanks, Tim
On Fri, Sep 26, 2014, at 12:22, Timothy Baldridge wrote:
It means a virtualizable was used a function that JIT did not trace through (a "residual call"). Hopefully, you can either allow the JIT to trace through that call or get the function to not use the virtualizable.
ABORT_ESCAPE means that the virtualizable was accessed from outside the JIT during tracing. This is a big no-no, virtualizables are meant to be used *only* from the JIT and not from the outside. If you look at the trace up to that point, it should be relatively obvious what's happening (e.g. something is a call and not inlined). The trace is an argument to the JIT hook. On Fri, Sep 26, 2014 at 6:22 PM, Timothy Baldridge <tbaldridge@gmail.com> wrote:
So I've tried several things, but I'm still unable to figure out where the trace ends. It seems that the green values handed to the hook are for the start of the trace, which doesn't really help me with finding out where the trace aborts. "operations" seems to be a list of trace operations. I tried printing .getarglist() off the last item in that list, but I'm not exactly sure what that data contains. What I'm trying to get to is something that says "at a call to function X you tried to pass in a frame, now we have to force the frame". Any thoughts? Tim On Fri, Sep 26, 2014 at 10:28 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)
On Fri, Sep 26, 2014, at 12:22, Timothy Baldridge wrote:
It means a virtualizable was used a function that JIT did not trace through (a "residual call"). Hopefully, you can either allow the JIT to trace through that call or get the function to not use the virtualizable.
ABORT_ESCAPE means that the virtualizable was accessed from outside the JIT during tracing. This is a big no-no, virtualizables are meant to be used *only* from the JIT and not from the outside. If you look at the trace up to that point, it should be relatively obvious what's happening (e.g. something is a call and not inlined). The trace is an argument to the JIT hook. On Fri, Sep 26, 2014 at 6:22 PM, Timothy Baldridge <tbaldridge@gmail.com> wrote:
So I've tried several things, but I'm still unable to figure out where the trace ends. It seems that the green values handed to the hook are for the start of the trace, which doesn't really help me with finding out where the trace aborts. "operations" seems to be a list of trace operations. I tried printing .getarglist() off the last item in that list, but I'm not exactly sure what that data contains. What I'm trying to get to is something that says "at a call to function X you tried to pass in a frame, now we have to force the frame". Any thoughts? Tim On Fri, Sep 26, 2014 at 10:28 AM, Maciej Fijalkowski <fijall@gmail.com> wrote:
-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)
participants (3)
-
Benjamin Peterson -
Maciej Fijalkowski -
Timothy Baldridge