This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: libgcj merging and VMStackWalker
- From: Andrew Haley <aph at redhat dot com>
- To: "Jeroen Frijters" <jeroen at sumatra dot nl>
- Cc: "Bryce McKinlay" <mckinlay at redhat dot com>, "Tom Tromey" <tromey at redhat dot com>, "GNU Classpath Project" <classpath at gnu dot org>, "GCJ Hackers" <java at gcc dot gnu dot org>
- Date: Tue, 16 May 2006 10:52:35 +0100
- Subject: RE: libgcj merging and VMStackWalker
- References: <D92197D0A6547B44A1567814F851FA68180AD4@LEMBU.sumatrasoftware.com>
Jeroen Frijters writes:
> 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 GetCallingClass() is called.
> > java.lang.reflect and ResourceBundle are two examples where
> > it is useful - we never want ResourceBundle.class or
> > Field.class, for example, to be returned there.
>
> None of the above really applies to VMStackWalker.getCallingClass(). It
> has well defined semantics and requires no hacks or workarounds, only a
> VM that can reliably walk the stack (i.e. know which frames are non-Java
> and prevent inlining from losing frames).
I think Jeroen is right about this one.
With regard to inlining, gcj is careful not to inline across classes,
but sibcall optimizations can cause stack frames to disappear
altogether. We should perhaps investigate that.
Andrew.