On Saturday, July 7, 2012, Alex Cruise wrote: > Forgive me if this is a naive question, but as regards the > caller/current-method question, since you have the complete AST in front of > you, why not just synthesize extra arguments to any method that happens to > use the caller or __method__ magic? >
Again, one of JRuby's "features" gets in the way of a simple approach; we have an interpreter too. The dance goes sort of like this: * JRuby is mixed-mode, and has an interpreted phase before code becomes JVM bytecode * Generating back traces (or otherwise inspecting the call stack) requires that we splice together the "native" and interpreter traces * As a result, any stack inspection requires a full Java stack trace plus the splicing logic (and the stack trace is by far the most expensive part of this) It may be possible for us to pass it from the compiler and if it's not present pull off interpreter backtrace frames, but it's obviously more complicated. My ideal situation would be asking the JVM for the top N frames and reducing the cost of stack inspection by M/N where M is the normal full stack trace it generates for us. > If it's at most the immediate caller that the callee is interested in, > well, that is a service the compiler can provide, no stack trace > skullduggery required. > > And, of course, for errno, there is a middle ground between exceptions and > magical in-band return values--in Scala-land we call it Either. When you're > a whole-program compiler (or are allowed to pretend you are one until a > monkey comes along) you can feel free to rewrite everyone's returns for > your own optimization. Whether that turns out to be a win in the long run > is, of course, a different question. :) > > Alas, for want of an effect system... :) > The idea of having a separate out-of-band mechanism isn't bad, but unfortunately people have written a lot of Ruby code around the idea that errnos are exceptions. So either we'd need to check return values for the exceptional path and raise it ourselves, or they'd have to change all that code. For what it's worth, people *are* starting to realize (with great effort on our part) that anything that triggers an exception or inspects the stack is probably way more expensive than its worth. As JRuby increases in performance over the other implementations, the benefits of avoiding stack inspection should start to become apparent. But in the short term...I'd like to understand what makes stack trace generation in the JVM slow and help explore what we can do to improve it. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
