C++ to JVM compiler

[jhc0033]

There used to be an alpha quality JVM backend for RedHat's branch of
GCC, but it was abandoned, because FOSS luminaries did not approve of
Java (strange, because both are out to crush Microsoft)

Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

Let me list the advantages:

* definitively determine memory corruption caused by a C++ program
(valgrind and VC++2005's debug mode help, but can not always detect
it; also they are much slower than JVM; it would also be nice to be
able to detect uninitialized memory access, but I don't think JVM can
help with that, since it has everything initialized)

* call C++ programs more easily from Java, presumably

* run C++ on some exotic platforms with JVM and no C++ compiler (rare)

* run some C++ code faster (Java sometimes beats C++ on numerics-heavy
tests - currently rare, but things seem to be changing in favor of
JIT)

* run C++ safely - I know there are arrogant C++ coders who would
claim that their C++ code can not be exploited, but is there an
automated way to prove that?

(This could make a great summer-of-code project, unless it's too hard
- I don't actually know)

[Razii]

On Thu, 24 Apr 2008 01:50:35 -0700 (PDT), "jh*****@gmail.com"
<jh*****@gmail.comwrote:

>Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

http://nestedvm.ibex.org/

NestedVM provides binary translation for Java Bytecode. This is done
by having GCC compile to a MIPS binary which is then translated to a
Java class file. Hence any application written in C, C++, Fortran, or
any other language supported by GCC can be run in 100% pure Java with
no source changes.

[jhc0033]

On Apr 24, 2:03 am, Razii <[e-mail]:

On Thu, 24 Apr 2008 01:50:35 -0700 (PDT), "[e-mail]"

<[e-mail]:

Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

http://nestedvm.ibex.org/

NestedVM provides binary translation for Java Bytecode. This is done
by having GCC compile to a MIPS binary which is then translated to a
Java class file. Hence any application written in C, C++, Fortran, or
any other language supported by GCC can be run in 100% pure Java with
no source changes.

Very interesting. Although, for C++ debugging, I don't think this
approach would always work for memory corruption detection, e.g.

#include <iostream>

struct pr {
double x;
double get_y() const { return y; }
pr() : x(0), y(0) {}
private:
const double y;
};

int main() {
pr p;
(&p.x)[1] = 3; // write to const private y
std::cout << p.get_y() << '\n';
}

[Andrea Francia]

jh*****@gmail.com wrote:

Very interesting. Although, for C++ debugging, I don't think this
approach would always work for memory corruption detection, e.g.

I don't think that C++ memory debugging issues can be solved changing
the compiler target machine.

I think that difficulties from debbugging memory uses of C++ programs
arises from the C++ language specification.

I think the best way of finding them is the use of specific C++ tools
for memory error detection.

--
Andrea Francia
http://www.andreafrancia.it/

[Joshua Cranmer]

jh*****@gmail.com wrote:

Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

Any C++-to-JVM compilation would have to be imprecise and rely on
several heuristics. Pointer arithmetic, rather common in C++ code, does
not convert to JVM bytecode well. Quirks of templates in C++ make
conversion to Java generics near impossible unless Java gains
reification. Finally, any crazy stuff I could do with function pointers
would not translate well.

* run some C++ code faster (Java sometimes beats C++ on numerics-heavy
tests - currently rare, but things seem to be changing in favor of
JIT)

This is a large bone of contention, but the two languages are more or
less equally fast these days. Likely the C++ code would be slowed down
as some imprecise translations would use hackier crutches.

* run C++ safely - I know there are arrogant C++ coders who would
claim that their C++ code can not be exploited, but is there an
automated way to prove that?

GCC dehydra? <http://wiki.mozilla.org/Dehydra_GCC>. Of course, you have
to write the tests first.

(This could make a great summer-of-code project, unless it's too hard
- I don't actually know)

I am not an expert in this area, but I think it would be on the harder
side. The GSoC application time frame for 2008 has already passed, though...

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[Kai-Uwe Bux]

Joshua Cranmer wrote:

jh*****@gmail.com wrote:

>Now that Java is going open-source again, I hope this project will be
resurrected. C++ and Java are the most widely used languages. It's a
shame that C++ can not be compiled to JVM, even though there is a ton
of platforms that it can be compiled to, and there is a ton of
languages that do compile to JVM.

Any C++-to-JVM compilation would have to be imprecise and rely on
several heuristics. Pointer arithmetic, rather common in C++ code, does
not convert to JVM bytecode well. Quirks of templates in C++ make
conversion to Java generics near impossible unless Java gains
reification. Finally, any crazy stuff I could do with function pointers
would not translate well.

Huh? Isn't JVM Touring complete? If so, it is simply equivalent to the
abstract machine defining the observable behavior of C++ programs.
Consequently, it will be possible to compile any C++ program to JVM in a
standard compliant way. It seems that you are imposing an additional
requirement: that high level C++ construct should be matched with Java
concepts.

>* run some C++ code faster (Java sometimes beats C++ on numerics-heavy
tests - currently rare, but things seem to be changing in favor of
JIT)

This is a large bone of contention, but the two languages are more or
less equally fast these days. Likely the C++ code would be slowed down
as some imprecise translations would use hackier crutches.

Maybe, I misunderstand. Could you define what you mean by "imprecise
translation"?
[snip]
Best

Kai-Uwe Bux

[jhc0033]

On Apr 24, 2:40 pm, Joshua Cranmer <[e-mail]:

Any C++-to-JVM compilation would have to be imprecise and rely on
several heuristics. Pointer arithmetic, rather common in C++ code, does
not convert to JVM bytecode well.

A pointer into an array, for example, is just a pair of
* array (reference)
* index into it
when the pointer points outside of the array the behavior is undefined
in C++, so I would like the Java version to fail in a case like that.

Quirks of templates in C++ make
conversion to Java generics near impossible unless Java gains
reification.

Templates shouldn't be translated into generics. C++ templates are
semantically closer to C++ macros than to Java generics.

Finally, any crazy stuff I could do with function pointers
would not translate well.

I don't see any difficulties there either.

* run some C++ code faster (Java sometimes beats C++ on numerics-heavy
tests - currently rare, but things seem to be changing in favor of
JIT)

This is a large bone of contention, but the two languages are more or
less equally fast these days. Likely the C++ code would be slowed down
as some imprecise translations would use hackier crutches.

For debugging, anything less than a 10x slow-down would beat MSVC++
debug mode, and anything less than a 100x slow-down would beat
valgrind.

* run C++ safely - I know there are arrogant C++ coders who would
claim that their C++ code can not be exploited, but is there an
automated way to prove that?

GCC dehydra? <http://wiki.mozilla.org/Dehydra_GCC>. Of course, you have
to write the tests first.

Not sure what it can do for me, but thanks for the link. I don't write
utterly bad C'ish C++ with strcpy, etc. However, I once spent days if
not weeks looking for an uninitialized value usage bug.

[Ian Collins]

Stefan Ram wrote:

"jh*****@gmail.com" <jh*****@gmail.comwrites:

>I don't see any difficulties there either.

Java has a 64 KByte limit for the size of methods.

http://bugs.sun.com/bugdatabase/view...bug_id=4262078

So a C++ function can not be translated to a Java method
(except for the case that it will not exceed 64 KBytes).

Anyone who writes methods bigger than 46K should be looking for another
line of work..

--
Ian Collins.

[Pete Becker]

On 2008-04-24 22:21:11 -0400, Kai-Uwe Bux <jk********@gmx.netsaid:

>
Huh? Isn't JVM Touring complete?

Alan Turing must be rolling over in his grave. <g>

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Lew]

Ian Collins wrote:

Stefan Ram wrote:

>"jh*****@gmail.com" <jh*****@gmail.comwrites:

>>I don't see any difficulties there either.

Java has a 64 KByte limit for the size of methods.

http://bugs.sun.com/bugdatabase/view...bug_id=4262078

So a C++ function can not be translated to a Java method
(except for the case that it will not exceed 64 KBytes).

Anyone who writes methods bigger than 46K should be looking for another
line of work..

Tell that to the automatic template and notJava-to-JVM programs that generate
the code, which is the major use case proffered for fixing this bug.

--
Lew

[LR]

Stefan Ram wrote:

"jh*****@gmail.com" <jh*****@gmail.comwrites:

>I don't see any difficulties there either.

Java has a 64 KByte limit for the size of methods.

http://bugs.sun.com/bugdatabase/view...bug_id=4262078

So a C++ function can not be translated to a Java method
(except for the case that it will not exceed 64 KBytes).

I'm sorry, but I don't see why this particular limitation of the JVM
limits what sort of C++ can be compiled to JVM code.

Is there some limitation in the JVM that prevents turning a single
method into a number of methods that are functionally equivalent to the
single method?

LR

[Steve Wampler]

LR wrote:

Is there some limitation in the JVM that prevents turning a single
method into a number of methods that are functionally equivalent to the
single method?

I don't think I'd call it a limitation of the JVM, but of automatic
language translations in general. It can be very hard to perform such
a split while preserving the original semantics and keeping the
efficiency close to what was there originally. Remember that you'd
like such a process to work correctly on the pathological cases as
well as the simple ones.

--
Steve Wampler -- sw******@noao.edu
The gods that smiled on your birth are now laughing out loud.

[jhc0033]

On Apr 25, 3:14 pm, [e-mail] (Stefan Ram) wrote:

Since the whole Scheme program is being compiled to one
large switch, this switch might be larger than 64 K.

Because (possibly small) closures are activated often,
one does not want to have a call overhead for each closure
activation.

The authors of Bigloo and Kawa would sure like to know that, because
of closures, their Scheme->JVM compilers are even MORE impossible
than C++ -JVM.