This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [boehm-gc] Import 6.3 alpha 1


On Wed, 30 Jul 2003, Bryce McKinlay wrote:
> > Bryce's is a good plan, if difficult to implement.  One way to
> > accomplish
> > it could be to JIT everything; allow the interpreter to load classes as
> > usual, then swap method pointers to interpreter trampolines for
> > compiled
> > functions.
>
> I don't believe that implementing the binary compatibility ABI itself
> requires the use of any JIT code generation or trampolines.

Right, it doesn't.  (I didn't claim otherwise.)

> The
> construction of the binary compatibility/link tables would be completed
> before any code from a given class is run, so there arn't any issues
> with having to synchronize & check link tables at runtime. (the
> statement in my post above should actually read "java.lang.Class
> objects would be  created at runtime as classes are _linked_ ")

Creating class instances on the heap could go a long way towards solving
the large root set problem.

Drifting off topic slightly, I think it does matter when exactly classes
are linked.  If I have a class A:

class A {
  B b() {
    return new B();
  }
}

should "new A()" cause B to be loaded?  (With the JRE it does not.)

This is an example of what blocks us from using gcj from "real world"
applications.

That said, I think the best of all worlds is a new ABI with a choice of
static linking or a JIT.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]