[coyotos-dev] Accept GCJ into the tool chain?
Jonathan S. Shapiro
shap at eros-os.com
Mon Nov 27 09:01:01 CST 2006
Okay, let's try to extract some facts here.
On Mon, 2006-11-27 at 00:46 -0500, Haplo wrote:
> I still say no. Support it? Sure, but as a widely used language for
> general applications? Java may have originally been designed for it,
> the security features (created for web applications),
Which security features get in the way of application building?
> fact that it requires a virtual machine,
This is incorrect. Consider GCJ.
> the fact that it would also possibly require making GUI components to
> work under coyotos (or at least not be ugly),
If we plan to support Java at all, we need to solve this problem anyway,
but this isn't really relevant to the construction of our cross-tools.
> and the fact that the application format for coyotos could be devised
> to be completely different from anything that could be easily done
> with java (while making life easier otherwise)...
I'm not sure what you mean here, and it seems to be worth exploring. Can
you expand on this?
> There are very few useful things you can do with java that aren't
> easier with C++
Speaking with the benefit of 20 years and >4M career lines of code
written in C++, this is complete bullshit. I certainly don't defend the
design decisions of Java, but for the vast majority of applications the
availability of GC and a viable exceptions model is extremely important
and useful. As a counter-example to your statement I would offer OpenCM,
where we decided to use the Boehm-Weiser collector to try to graft these
attributes back onto C++. It nearly destroyed OpenCM, which was
otherwise rock-stable. Indeed, if I had it to do over today I would use
Java or C# for OpenCM [not C# yet, because mono isn't mature enough.]
> and all of those things still run faster in native compiled C++.
Sometimes faster isn't the goal.
> I don't care what you say, virtual machines are inherently slow.
First, this flatly isn't true. What you are seeing in the market today
is virtual machines that are designed to do heavy optimization on
long-running programs. These machines are being applied to programs
whose dominant costs are their startup costs. It's an obvious recipe for
disaster. As a counter-example, consider our recent work on HDTrans,
which basically shows that the intrinsic overhead of dynamic translation
is about 2%.
However, I agree with your underlying point: current VMs are not very
clever about precompilation or generating code quickly, and this is a
The main reason that I think this isn't an issue is the availability of
GCJ, which can perform purely static, ahead-of-time compilation.
> You can compile some code to time some algorithms to find that out
> quite easily- native code is run directly while java code must run
> code to translate the java code which is then run, and even the best
> emulation will not run any CPU intensive task reasonably fast.
You might be interested to take a look at the HDTrans numbers.
More information about the coyotos-dev