> I guess I didn't explain the problem very well (and glancing at the
> gcj web site didn't show me the answer). For one thing, I'm assuming
> that gcj will do inlining.
I think right now it doesn't do much of that. Though I've known folk
who look at providing member access without a function call as a form
of inlining. (And more who laugh at that perspective! :-)
> Given the dynamic nature of Java (be able
> to load user specified classes at runtime), an ahead-of-time Java
> compiler cannot correctly do inline (let me know if you want an
> example). This can give a real advantage to a dynamic compiler like
> HotSpot.
There are methods that can safely be inlined in all cases (final ones),
and ones that can't ... you're talking about runtime profiling being
used to leverage the specific runtime circumstances (maybe a nonfinal
method is never overridden, so it's "effectively final"; or knowing
the range of some parameter, eliminating some code paths).
Sure, those techniques exist. Classic global optimization perspectives.
I'd want them applied over sealed package in any environment. You're
right that a "dynamic" compiler can optimize more arbitrary scopes, and
even change over time. But how many trustworthy systems are not built
mostly from strongly compartmentalized ("sealed") components?
> And there might be other optimizations like that too.
On the other hand, perhaps the system-wide costs of late compiling
models are more than their benefits, in many common application types.
We're talking about tradeoffs between early and late analysis, but
don't forget that those early analysis code paths (the GCC 3.0 backend)
are getting better all the time. It's likely there are more GCC users
than Hotspot users, and on more different OS platforms.
> It seems like if you know your set of classes is going to be static,
> then the ahead-of-time will be faster (especially if you save your
> previous run state), but if something creeps into your system that
> loads a class dynamically, you could have a hard to track down bug,
Those two "if"s are irrelevant without assuming a compiler bug; I
guess that's a third "if".
> unless gcj somehow detects that. It seems important for gcj users to
> understand the limitations.
All software has bugs. You can't imply that GCJ has a bug and then
use your implication as evidence of a GCJ limitation, at least without
a bug report in hand, evaluated as "can not fix".
- Dave
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
