This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [boehm-gc] Import 6.3 alpha 1
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Ranjit Mathew <rmathew at hotmail dot com>, <java at gcc dot gnu dot org>
- Date: Wed, 30 Jul 2003 09:53:05 -0400 (EDT)
- Subject: 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