On Apr 11, 2013, at 10:12 AM, Charles Oliver Nutter wrote:
> Unfortunately there's no API to get just a partial stack trace, via
> JVMTI or otherwise. The relevant code in Hotspot itself is rather
> simple; I started prototyping a JNI call that would allow getting a
> partial trace. Perhaps somet
d
>
> Kind regards,
>
> William
>
>>-Original Message-
>>From: Bob Foster [mailto:bobfos...@gmail.com]
>>Sent: Sunday, July 8, 2012 01:32 AM
>>To: jvm-langua...@googlegroups.com
>>Cc: 'Da Vinci Machine Project'
>>Subject: Re: [jvm-
-released
Kind regards,
William
>-Original Message-
>From: Bob Foster [mailto:bobfos...@gmail.com]
>Sent: Sunday, July 8, 2012 01:32 AM
>To: jvm-langua...@googlegroups.com
>Cc: 'Da Vinci Machine Project'
>Subject: Re: [jvm-l] Improving the performance of st
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
> Any thoughts on this? Does anyone else have need for
lighter-weight name/file/line inspection of the call stack?
Well, yes. Profilers do.
Recall Cliff Click bragging a couple of years ago at the JVM Language
Summit about how fast stack trace generation is in Azul Systems' OSs...and
knocking Hot
>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
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
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
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
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 year ago) moved to using the
Java stack trace as the source of o
10 matches
Mail list logo
