Re: Why Java is slow ?

Sean McDirmid wrote:


[ references ]


Thanks for the references. I will look.


> I'm not discounting anything. Even with Vortex-like optimizations
> (http://www.cs.washington.edu/research/projects/cecil/) though, the
> bounds of static optimizations are limited on what can be known before
> runtime. Despite rapid advances in compiler technology (which has
> basically been stagnate for the past 20 years),


My former colleagues at Rice surely disagree with you, and at least
one of them was hired to work at Javasoft. People are *still* farting
around trying to figure out how to make register allocation work
really well, and the addition of new architectural features and new
uses for what was once "more registers than we'll ever need" force
rethinking of old optimizations.


> Classes do not have to be unloaded unless they are replaced in the
> system. Also, if Class B depends on Class A and Class A is unloaded,
> then Class B MUST be unloaded also. This only makes sense, its basic
> reference counting.


No. You have not thought this problem through. Class A is derived
from class B; B does not depend upon A. Because of usage patterns,
some method within B, which calls a non-final method of B overridden
in A, acquires a "check-the-assumption-that this-is-really-an-A,
execute this inline code if so" test in it. If A is unloaded, then
the code generated for B must (perhaps, depending on runtime data
structures) be modified. B may not even be a candidate for unloading
(it could be a system class, such as Vector or AbstractSet).


> Does it work? How do you know your compiler works? You can only test
> it, formal verification of it would be an NP-complete problem.


I'm almost certain that your formal verification cost estimate is
wrong :-). In practice, we do it with unit testing, system testing,
exhaustive testing, and pathological input testing. We've got some
other tricks in our bag that I cannot discuss.


> Same issues exist, you can always recreate a situation in a dynamic
> compiler, its just of a higher order of recreation than a static
> compiler.


"just of a higher order". Nice. The compiler's behavior now depends
on your thread scheduling algorithms, since that may change the
distribution of hot spots and the order in which they are encountered.
It now depends upon your garbage collector, since what finalizers are
encountered when and when they are run now affects when code runs.
Instead of one binary to inspect for bugs, there's plural binaries to
inspect for bugs.


> Think this:
>
> static compiler - 2 dimensions (X is data-in, Y is data-out)
> dynamic compiler - 3 dimensions (additional dimension represents the
> state of the machine).


I already think that; what you describe is a recipe for testing
headaches.


> If you can reproduce the machine state exactly and there is no
> indeterminism in the code (that is, given the same set of inputs, it
> will produce the same outputs), you must be able to reproduce it.


If pigs had wings .... The difficulty is that some of the bugs will
not choose to appear in the easily-reproducible world.


> The indeterminism of the environment, such as threads, user
> interaction, etc...affect both statically compiled code and
> dynamically compiled code.


There are ways to control this, agreed, but it requires detailed
observation of the runtime (thread switching, for example) that become
much more difficult on a multiprocessor. If the bug chooses not to
appear when you are running the trussed system, what then?


David Chase
NaturalBridge LLC
--

Return to the comp.compilers page.
Search the comp.compilers archives again.