Re: JVM as UNCOL, was ANDF/TDF

Sunil Kumar Anand wrote:


> The question of porting C and C++ does not arise at all because C and
> C++ have pointer accessses which Java does not allow at any cost.


You could simulate the address space as a single byte array hence you
got pointers! However it would probably not be very efficient.


> Regarding aothers,the eficciency has been the prime
> consideration. Java Bytecode(which is what Java Programmers call class
> files) was designed for interpretation.But soon it was found that
> interpretation is slower and then switched over to JIT(Just In Time
> compilation).


This is a old myth. Java byte code was from the start designed for
both interpretation and compilation (can you design a instruction set
specifically for either interpretation or compilation?). This has been
stated by Gosling one several occasions and is clear from the original
Oak/Java papers. The only reason for Java originally being interpreted
was development time - its much faster to develop an interpreter than
a compiler, especially if the compile time is a main focus.


> But the problem with JIT is it takes too much time to start an
> application(since it has to compile to native code and then start
> execution).


It compilers single methods in a "first use" basis. First time the method
is invoked will it be compiled and the compiled code will be executed
instead.


> The next advancement is Hotspot compiling.In this method initially the
> program starts executing in interpreter mode and profiling is done to
> see which part of the program is being executed more(effectively it is
> called "hotspot") and these hotspots are compiled so that whenever
> next time call to that part is made u can just invoke the compiled
> code.
>
> Just like Java has Bytecode, C# has MSIL(Microsoft Intermediate
> Language). That's how .NET supports multiple languages on its
> platform.
>
> MSIL instruction is designed in such a way that it is easy to JIT
> compile rather than interpret.


The MSIL is largely equivalent to the Java byte code so how can it be
design specifically for compilation when bye code supposedly is design
for interpretation?


It is all a part of Microsoft propaganda. They say: look we got this
great technology that is design specifically for compilation whereas
the "old" java technology is only interpreted as thus slow. The truth
is that both instruction sets and virtual machine are very alike and
that Microsoft has chosen not to support interpretation (for marketing
reasons I believe) whereas Java does. In my opinion the Java solution
is better as interpretation is not always bad. First of all, Java is
used on devices where compilation is not possible because of lack of
resources. Secondly, even on larger system where run-time compilation
is possible it is not always profitable to compile each method. Some
methods are simply too small or too seldom invoked for the cost of
compiling them to be regained by the faster execution of their
compiled counterparts, whereas other method are so critical that it is
profitable to use more time compiling them than normally possible for
the JIT-compilers. The Hotspot JVM/compiler is a good example on this.


> Interesting research area is how best we can exploit the instruction
> set to optimize the code generated by JIT compiler.Also how good
> will the performance of this MSIL when compared to Java bytecode is
> still not known.


I will expect it to be similar.


/Jesper

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