RE: gnu.classpath.VMStackWalker

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

 



Jeroen Frijters writes:
 > Andrew Haley wrote:
 > > The current gnu.classpath.VMStackWalker interface is inefficient.
 > > 
 > > Sun provide:
 > > 
 > >   sun.reflect.reflection.getCallerClass(int depth)
 > > 
 > > and for the same function we would do
 > > 
 > >   VMStackWalker.getClassContext()[depth];
 > > 
 > > You see the difference: Classpath's VMStackWalker enumerates the whole
 > > stack, whereas Sun's only has to enumerate a few stack frames.
 > 
 > Actually, Sun simply has a bad design. There is no need for arbitrary
 > depth caller class discovery (as our codebase demonstrates).

How, exactly?  I see horrors like 

  /**
   * Get the class loader associated with the Class returned by
   * <code>getCallingClass()</code>, or <code>null</code> if no such class
   * exists or it is the boot loader. This method is an optimization for the
   * expression <code>VMStackWalker.getClassLoader(getClassContext()[1])</code>
   * and should return the same result.
   *
   * <p>
   * VM implementers are encouraged to provide a more efficient
   * version of this method.
   */
  public static ClassLoader getCallingClassLoader()
  {
    Class[] ctx = getClassContext();
    if (ctx.length < 3)
      return null;
    return getClassLoader(ctx[2]);
  }

in several places.

 > However, now that we've got the reference j.u.c implementation it
 > makes sense to add a method to VMStackWalker that enables us to
 > more efficiently implement sun.reflect.reflection.getCallerClass.

Right.

Andrew.


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

  Powered by Linux