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: <tromey at redhat dot com>, "GNU Classpath Project" <classpath at gnu dot org>
- Cc: "GCJ Hackers" <java at gcc dot gnu dot org>
- Date: Sun, 14 May 2006 22:41:22 +0200
- Subject: RE: libgcj merging and VMStackWalker
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: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org]
> On Behalf Of Tom Tromey
> Sent: Sunday, May 14, 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, 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' argument to
> VMStackWalker.getCallingClass and VMStackWalker.getCallingClassLoader.
> This argument would name the immediate caller, and these methods
> would be changed to return the class just above the argument class in
> the stack trace.
>
> With this change I think I could immediately merge Logger,
> ResourceBundle, Package, and parts of SecurityManager and the little
> CORBA differences.
>
> I don't think this would overly affect performance (a big worry on the
> gcj end) or maintainability on the Classpath side.
>
> It would require a small VM change. However, other VMs could simply
> add this method argument and then ignore it, and things would continue
> to work as they do today.
>
> I've appended the VMStackWalker change so folks can see what it looks
> like. I didn't include all the other changes, which are basically
> mechanical.
>
> On the libgcj side, VMStackWalker would be just a simple wrapper
> around the existing stack-walking code. The class argument would make
> it simpler for our stack walker to know when to start looking for the
> 'caller' class -- it would skip both VMStackWalker and the immediate
> (internal) caller.
>
> Comments?
>
> Tom
>
> Index: VMStackWalker.java
> ===================================================================
> RCS file:
> /cvsroot/classpath/classpath/vm/reference/gnu/classpath/VMStac
> kWalker.java,v
> retrieving revision 1.6
> diff -u -r1.6 VMStackWalker.java
> --- VMStackWalker.java 13 Nov 2005 22:29:45 -0000 1.6
> +++ VMStackWalker.java 13 May 2006 23:28:36 -0000
> @@ -78,7 +78,7 @@
> * VM implementers are encouraged to provide a more efficient
> * version of this method.
> */
> - public static Class getCallingClass()
> + public static Class getCallingClass(Class context)
> {
> Class[] ctx = getClassContext();
> if (ctx.length < 3)
> @@ -97,7 +97,7 @@
> * VM implementers are encouraged to provide a more efficient
> * version of this method.
> */
> - public static ClassLoader getCallingClassLoader()
> + public static ClassLoader getCallingClassLoader(Class context)
> {
> Class[] ctx = getClassContext();
> if (ctx.length < 3)
>