Current Status

[Hans Erik Martino Hansen]

On Wed, Feb 17, 1999 at 12:08:04PM -0500, Jeff Sturm wrote:
> Hans Erik Martino Hansen wrote:
> > 
> > On Wed, Feb 17, 1999 at 09:31:40AM -0500, Jeff Sturm wrote:
> > > You can't inline across class boundaries to be sure... but private
> > > methods are normally safe to inline.  They are common enough to be a
> > > worthwhile optimization.
> > 
> > It is only when compiling to .class files you cannot inline across
> > class boundaries. Example
> > 
> > class A {
> >   void f() { do this and do that; }
> > }
> > 
> > class B {
> >   void f() { A a = new A(); a.f(); }
> > }
> > 
> > When calling a.f() we know exactly what f is being called, it cannot
> > be overrided by subclassing A. And in contrary to compiling to .class
> > files A cannot be recompiled either. No dynamic linking here. So we
> > can just as well inline it.
> 
> But what if class A has private fields, e.g.:
> 
> class A {
>   private int x;
>   void f() { x = 0; }
> }
> 
> Then it would be illegal for B to inline A.f() since the bytecode would
> be accessing a private member outside of its enclosing class.

But, since we generate native code from bytecode, we can inline
methods in native code even though they are not inlined in the
bytecode. 

Native code (JIT or executables) is not running in a sandbox and
doesn't have to obey the rules of bytecode. It only have to obey the
semantics of java. The rule saying that you cannot access private
fields from another class _in java code_ is not violated.

> -- 
> Jeff Sturm
> jsturm@sigma6.com

/erik
-- 
 \|/ ____ \|/  Erik M. Hansen <martino@daimi.aau.dk>
 "@'/ oo \`@"  http://www.daimi.aau.dk/~martino/
 /_| \__/ |_\  Fuglesangsalle 69, DK-8210 Århus V, Denmark. 
    \__U_/     Phone office (+45) 8942 3217, Phone home 86106814