C actually runs very well on the JVM using Java bytecodes as shown by work of 
Matthias Grimmer [1]. This includes interoperability with other languages 
running on top of the JVM like JavaScript [2]. Current direction of this work 
is to extend to LLVM for expanding the support of AOT compiled languages beyond 
C. Also, the work includes a safe execution mode that runs C with security 
guarantees.

The coroutine [3] and continuation [4] work of Lukas Stadler demonstrates 
efficient implementations of those concepts on the JVM as well.

Another major aspect that has changed since 1995 are the advancements in the 
area of escape analysis and partial escape analysis to avoid object allocations 
[5, 6]. This makes modelling numbers as classes a lot more efficient and indeed 
enables the optimization of the calculations into “direct machine instructions” 
even when a lot of temporarily boxed objects are involved.

- thomas

[1] http://dl.acm.org/authorize.cfm?key=N96093 
<http://dl.acm.org/authorize.cfm?key=N96093>
[2] http://dl.acm.org/authorize.cfm?key=N96005 
<http://dl.acm.org/authorize.cfm?key=N96005>
[3] http://ssw.jku.at/Research/Papers/Stadler11Master/Stadler11Master.pdf 
<http://ssw.jku.at/Research/Papers/Stadler11Master/Stadler11Master.pdf>
[4] http://ssw.jku.at/Research/Papers/Stadler09/Stadler09a.pdf 
<http://ssw.jku.at/Research/Papers/Stadler09/Stadler09a.pdf>
[5] http://ssw.jku.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf 
<http://ssw.jku.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf>
[6] http://ssw.jku.at/Research/Papers/Stadler14PhD/ 
<http://ssw.jku.at/Research/Papers/Stadler14PhD/>


> On 17 Apr 2015, at 01:19, John Rose <john.r.r...@oracle.com> wrote:
> 
> James made some relevant comments on the JVM as a multi-language engine.
> 
> It was just a little while ago, as I noticed going through some old files.
> 
> Folks are still working on specialized allocation (aka. value types) and 
> continuations (aka. coroutines & tailcall).
> 
> Also, C is no longer "right out"; see Project Panama.
> 
> — John
> 
> From: owner-hotjava-interest-dig...@java.sun.com
> To: hotjava-interest-dig...@java.sun.com
> Subject:   hotjava-interest-digest V1 #24
> Date: Sat, 1 Apr 1995 17:34:17 -0800
> Reply-To: hotjava-inter...@java.sun.com
> X-Info: To unsubscribe, send 'unsubscribe' to 
> hotjava-interest-digest-requ...@java.sun.com
> 
> hotjava-interest-digest        Sunday, 2 April 1995        Volume 01 : Number 
> 024
> 
> 
> ----------------------------------------------------------------------
> 
> From: rich...@cogsci.ed.ac.uk
> Date: Fri, 31 Mar 95 13:30:04 BST
> Subject: How general is the Java bytecode language?
> 
> Has anyone looked at the possibility of compiling languages other than
> Java to the Java bytecodes?  In particular, there seem to be many people
> interested in using Scheme as a scripting language, and the ability
> to download Scheme programs into HotJava would be nice.
> 
> - -- Richard
> 
> ----------------------------------------------------------------------
> ...
> 
> ----------------------------------------------------------------------
> 
> 
> From: j...@scndprsn.eng.sun.com (James Gosling)
> Date: Fri, 31 Mar 1995 20:34:24 +0800
> Subject: Re: How general is the Java bytecode language?
> 
>> Has anyone looked at the possibility of compiling languages other than
>> Java to the Java bytecodes?  In particular, there seem to be many people
>> interested in using Scheme as a scripting language, and the ability
>> to download Scheme programs into HotJava would be nice.
> 
> It's reasonably general, although the security restrictions make some
> languages hard.  C and C++ with general pointer arithmetic are right
> out.  Fortran's pass-by-reference call semantics and "common" are
> tough.  Pascal is pretty straightforward.  Scheme is easy or hard,
> depending on how good you want the performance to be: the invocation
> model in Java is very C like with no provision for continuations.
> Continuations can be handled as classes & the key trick in a compiler
> would be to decide when a full-blown continuation can be optimized
> away.  The story is similar with datatypes like numbers: in general,
> every number would be an instance of some class & the trick is to
> optimize that into direct machine instructions.  Using the Java
> bytecodes is likely to be somewhat less than optimal because things
> like continuations and general numbers need to be done as classes, the
> underlying engine doesn't have things like specialized allocators for
> boxed integers.
> 
> 
> Note to Sun employees: this is an EXTERNAL mailing list!
> Info: send 'help' to hotjava-interest-requ...@java.sun.com
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to