Re: Why Java is slow ?

[comp.compilers added to this cross posting]


This thread is discussing the potential virtues and drawbacks of
dynamic compilation versus static compilation of mainly Java
byte-code.


David Chase wrote:
>
> So much? How much? Anybody done any measurements?
>
> And that world-beating dynamic-compiling C++ system is sold
> by who? Or, a prototype is described in what paper?


Well, I looked for a list of papers in addition to the UW dyanamic
compilation project.


http://cas.ibm.ca/projects/oo-opt95.html
http://www.research.ibm.com/daisy/home.html
http://www.dcs.ex.ac.uk/~david/research/dynamic.html


> The problem with these examples is that they are posed by people who
> haven't worked on a static system, and who aren't trying very hard
> (in their little imagined static system) to make the static system
> work well, and they seem to discount the costs of measurement,
> assumption-checking, and compilation. Inlining can have a wonderful
> effect on the quality of your information (if, for instance, you
> inline the routine that actually allocates an object, then you've
> captured the object's actual type, and you don't need to check it.)


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),


Correct, there is overhead in dynamic compilation, and I don't think
it will be the only solution, but added as another solution. Embedded
and low end systems definitely will not be able to handle there own
compilation, overhead is too great. There dependence will be on a
mixture of static compilation and compilation servers.


> I suspect, too (based on all the analysis problems I've ever fiddled
> with) that class unloading will make life terribly rough; to unload
> a class, you'll need to invalidate all the code that was compiled
> depending on that class, which means that you'll need to keep data
> structures reflecting that information, including where it was
> inlined and where information was propagated out of the inlining.
> Code-ungeneration, if you wish to call it that. Big fun. Don't
> forget that you *might* be executing the method containing that
> code-to-be ungenerated in another thread while you are unloading
> classes.


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.


> The major problem with dynamic compilation is a little trickier: How
> do you know that it works? How do you test it? How do you debug
> it? Static compilers have the advantage that the large majority of
> their bugs are repeatable, and because they generate a static piece
> of code, a programmer can sit down and look at it, binary search it,
> whatever.


Yes, static software is always easier to debug than dynamic software.
It is much easier to debug "Hello World" since its output is the same
all the time, but once you have '"Hello World at " + date', it gets a
bit trickier. Today, static compilers are one way boxes, pump data
through, get data out. A dynamic compiler is much more advanced and is
much more fluid.


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. 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.


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).


> A dynamic compiler, on the other hand, might behave a little
> differently each time (with finalizers, every program is
> multithreaded), and the "compiler" (or perhaps the "uncompiler") has
> to deal with thread synchronization problems (remember, the compiler
> is invoked whenever a piece of code is determined to be frequently
> executed, not just at class loading).


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. The
indeterminism of the environment, such as threads, user interaction,
etc...affect both statically compiled code and dynamically compiled
code.


> Patience, patience. You'll note that HotSpot isn't done either,
> despite all the resources Sun has to throw at it.


Agreed. But then Sun is mostly slow at everything. I doubt
the delays are for more technical reasons rather than marketing.


Sean
--

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