This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
invokespecial on abstract method
- From: Andrew Haley <aph at redhat dot com>
- To: Erik Poupaert <erik dot poupaert at freestyler-toolkit dot org>
- Cc: bryce at mckinlay dot net dot nz, gcj at stuellenberg dot de, java at gcc dot gnu dot org
- Date: Fri, 3 Oct 2003 17:05:23 +0100
- Subject: invokespecial on abstract method
- References: <20031003173809.5d196b57.erik.poupaert@freestyler-toolkit.org>
Erik Poupaert writes:
>
> >>> I'm sure it wouldn't be hard for Sun to make their VM fully evaluate
> >>> all linkage before running anything, if they wanted to do that. But by
> >>> design, Java doesn't.
>
> In terms of optimizing performance/footprints ahead-of-time, is
> there a cost associated to late linking? I somehow guess there
> is. More likely than not, this strategy of late linking may
> complicate other ongoing efforts that focus on these optimizations.
Yes. But if you really want to link statically without indirect
dispatch, you'll still be able to do that.
> There may be enormous advantages in doing exactly the opposite of
> what Sun does.
>
> When competing with the JDK, it may exactly be this different set
> of trade-offs, better attuned to particular situations, that could
> attract a sizeable following to GCJ.
Maybe. Please don't worry: I have no intention of disabling the
useful features of gcj. Even with indirect dispatch as the default,
you'll still be able to do something like
gcj a.java b.java c.java -o fluff.o
and all the references between a, b, and c will be direct. Indirect
dispatch only applies to external linkage.
Andrew.