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
, 2006 01:42
> To: GNU Classpath Project
> Cc: GCJ Hackers
> Subject: libgcj merging and VMStackWalker
>
> 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,
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,
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 simply. In fact I think it
just requires adding a 'Class' ar
13 matches
Mail list logo