libgcj merging and VMStackWalker

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 meaning
> > of 'muddle up', it adds a new method with -IMO - also clearly
> > defined semantics). It has the added advantage that it also
> > returns the method name, which is very useful in the logging API.
> 
> If I understand you correctly, this is a different issue from the one we
> were discussing. Tom wanted to change the existing API because he
> believed it wasn't implementable in gcj. If I understand you correctly,
> you want to add a new API to use in logging, right? Or does Aicas use a
> custom version of Class (for example) to relies on this API?

No, this is (ATM) only used by the logging API. However, we see a couple
more usecases for such an extension.

> > Any opinions about that approach?
> 
> It looks fine, but as long as it isn't needed by shared GNU Classpath
> code, it doesn't need to be part of the VM interface (IMO).

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.

/Roman

-- 
?Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.? - William Blake
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://developer.classpath.org/pipermail/classpath/attachments/20060516/95ed3b10/attachment.pgp

[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux