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: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- To: Jeff Sturm <jsturm at one-point dot com>
- Cc: Ranjit Mathew <rmathew at hotmail dot com>,java at gcc dot gnu dot org
- Date: Wed, 30 Jul 2003 14:22:57 +1200
- Subject: Re: [boehm-gc] Import 6.3 alpha 1
On Tuesday, Jul 29, 2003, at 17:59 Pacific/Auckland, Jeff Sturm wrote:
On Tue, 29 Jul 2003, Ranjit Mathew wrote:
That seemed to be what Bryce wanted to do:
http://gcc.gnu.org/ml/java/2002-06/msg00111.html
Thanks for the link! I'd forgotten about some of these discussions.
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. 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_ ")
The new ABI would solve a lot of problems, but it doesn't unfortunately present a better way to make sure classes get initialized at their "first active use" sites (ie the _Jv_InitClass problem), which is a bit of a thorn in the side of native java compilation. I think the best we can do here is improve the compiler so it is better at removing redundant initialization checks, moving them out of loops where possible, etc. tree-ssa should make this stuff easier.
Regards,
Bryce