Hello again,
Am Dienstag, den 16.05.2006, 14:25 +0200 schrieb Jeroen Frijters:
> Roman Kennke wrote:
> > Here (@Aicas) we faced a similar problem as described by Tom.
> > We came up with another possible (but similar) solution, which
> > doesn't 'muddle up' the VM interface (ok, depends on your m
Roman Kennke wrote:
> We could then merge some patches for java.util.logging, which
> would make use of this for more efficient logging. I think this
> would be useful for GNU Classpath. As it is now, we faced severe
> bottlenecks in applications that make use of the logging API.
Well then, by al
Roman Kennke wrote:
> Here (@Aicas) we faced a similar problem as described by Tom.
> We came up with another possible (but similar) solution, which
> doesn't 'muddle up' the VM interface (ok, depends on your meaning
> of 'muddle up', it adds a new method with -IMO - also clearly
> defined semanti
Hi Jeroen,
Am Dienstag, den 16.05.2006, 14:25 +0200 schrieb Jeroen Frijters:
> Roman Kennke wrote:
> > Here (@Aicas) we faced a similar problem as described by Tom.
> > We came up with another possible (but similar) solution, which
> > doesn't 'muddle up' the VM interface (ok, depends on your mea
Roman Kennke wrote:
> I also don't think I misunderstood the purpose of the VMStackWalker VM
> interface. As far as I understand it, this interface is there in order
> to provide more efficient access to stack information than
> Thread.getStackTrace().
Tom's proposal was about VMStackWalker.getCal
Roman Kennke wrote:
> > If gcj cannot reliably walk the stack at the moment,
>
> I just want to add one comment here. The problem (at least as we found
> it @aicas) is not to reliably walk the stack, the problem is that the
> VMStackWalker interface is not well suited for 'walking' the
> stack.
Hi again,
> If gcj cannot reliably walk the stack at the moment,
I just want to add one comment here. The problem (at least as we found
it @aicas) is not to reliably walk the stack, the problem is that the
VMStackWalker interface is not well suited for 'walking' the stack. You
can pull the whole
Hi there,
Am Dienstag, den 16.05.2006, 09:29 +0200 schrieb Jeroen Frijters:
> Bryce McKinlay wrote:
> > GetCallingClass(Class) is intended for situations where you
> > really want the caller of an external API into the class,
> > but due to overloaded methods or inlining may have an
> > indetermi
Bryce McKinlay wrote:
> GetCallingClass(Class) is intended for situations where you
> really want the caller of an external API into the class,
> but due to overloaded methods or inlining may have an
> indeterminate number of frames between the external method
> and the site at which GetCallingCla
Andrew Haley wrote:
Tom Tromey writes:
> This week I spent some time looking at the libgcj/Classpath merge
> situation. After removing all the simple merges that hadn't yet been
> handled for some reason, I looked at VMStackWalker a little.
>
> I think this merge could be done fairly simpl
Hi,
I still don't get it. Why can you walk up one frame from the context
class, but not two frames from the VMStackWalker class?
Regards,
Jeroen
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Tom Tromey
> Sent: Sunday, May 14, 2006 01:42
> To: G
Hi Tom,
On Sat, 2006-05-13 at 17:41 -0600, Tom Tromey wrote:
> I think this merge could be done fairly simply. In fact I think it
> just requires adding a 'Class' argument to
> VMStackWalker.getCallingClass and VMStackWalker.getCallingClassLoader.
> This argument would name the immediate caller,
12 matches
Mail list logo
