Re: Improving the performance of stacktrace generation

2013-04-10 Thread Jason Zaugg
On Sunday, July 8, 2012 12:03:34 AM UTC+2, Charles Oliver Nutter wrote: > > * Exceptions as non-exceptional or moderately-exceptional method results > > In this case I'm specifically thinking about Ruby's tendency to > propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example > are th

Re: Improving the performance of stacktrace generation

2012-07-07 Thread Mark Roos
>From Charile Any thoughts on this? Does anyone else have need for lighter-weight name/file/line inspection of the call stack? Yeah I need it for my debugger and error displays. But I need it for suspended threads ( my debugging steps ) as well as for exceptions. And for exceptions it would b

Re: Improving the performance of stacktrace generation

2012-07-07 Thread Rémi Forax
On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote: > On Saturday, July 7, 2012, Rémi Forax wrote: > > You can use Throwable.getStackTraceElement() > which is package visible and OpenJDK specific but at least > it will be faster for all VMs that uses OpenJDK. > > I'll certainly explore

Re: Improving the performance of stacktrace generation

2012-07-07 Thread Charles Oliver Nutter
On Saturday, July 7, 2012, Rémi Forax wrote: > You can use Throwable.**getStackTraceElement() > which is package visible and OpenJDK specific but at least > it will be faster for all VMs that uses OpenJDK. > I'll certainly explore that to see if it improves the situation. If it's faster, it might

Re: Improving the performance of stacktrace generation

2012-07-07 Thread Rémi Forax
On 07/08/2012 12:03 AM, Charles Oliver Nutter wrote: > Today I have a new conundrum for you all: I need stack trace > generation on Hotspot to be considerably faster than it is now. > > In order to simulate many Ruby features, JRuby (over)uses Java stack > traces. We recently (JRuby 1.6, about a ye