This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: libgcj merging and VMStackWalker
- From: "Jeroen Frijters" <jeroen at sumatra dot nl>
- To: "Bryce McKinlay" <mckinlay at redhat dot com>, "Andrew Haley" <aph at redhat dot com>
- Cc: "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 09:29:25 +0200
- Subject: RE: libgcj merging and VMStackWalker
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).
If gcj cannot reliably walk the stack at the moment, I suggest modifying
the code generator to add the class argument to the
VMStackWalker.getCallingClass(), instead of muddling up the VM interface
with that.
Regards,
Jeroen