Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > comp.compilers > #656

Re: Thoughts on the JVM as a compilation Target?

From torbenm@diku.dk (Torben Ægidius Mogensen)
Newsgroups comp.compilers
Subject Re: Thoughts on the JVM as a compilation Target?
Date 2012-05-29 17:40 +0200
Organization SunSITE.dk - Supporting Open source
Message-ID <12-05-027@comp.compilers> (permalink)
References <12-05-015@comp.compilers> <12-05-016@comp.compilers> <12-05-024@comp.compilers>

Show all headers | View raw


BGB <cr88192@hotmail.com> writes:


> maybe trying for a small list here:
> lack of unsigned operations;
> lack of pointers;
> lack of function or method references;
> lack of variable references (need not be pointers);
> lack of a lexical environment;
> lack of good dynamic types;
> lack of package-scoped declarations;
> lack of operators over object types;
> lack of pass-by-value / structure types;
> lack of RAII or similar;
> lack of a good C FFI.

A few more:

 - Lack of proper tail calls.

   This can be implemented using trampolines, but this is inefficient
   and kludgy.  Scala (AFAIR) implements only tail recursion and not
   proper tail calls because of this limitation.

 - Lack of non-nullable reference types.

   Object/reference types are implicitly always nullable, though it is
   simple to statically verify non-nullable types.  The consequence is
   that the VM always has to check for null pointers when following
   references, even when the reference can never be to null.

 - Lack of structural type equivalence.

   This means that you have to resort to kludges when implementing pair
   types and similar structures, and it gives problems when implementing
   (type-safe) polymorphic pair types.  Which leads to

 - Lack of parametric polymorphism.

   Generics is currently implemented with type erasure to Object and
   (runtime-checked) downcasts, which is inefficient.  Statically
   verified parametric polymorphism could avoid this.

 - Lack of an unbounded integer type.

   Though this can be implemented using JVM primitives, it is slow and
   kludgy to do so.  Many languages (Scheme, Haskell, ...) have
   unbounded integers.

 - Inefficient exception handling.

   This was a real limitation for some students that tried to implement
   a subset of Prolog in JVM.  Exceptions were the natural way to
   implement cut (!), but it was just way too slow.

This is what I could think off at the top of my head, but I'm sure more
would come up if I tried to use JVM as target for a realistically-sized
language (as opposed to toy languages).

	Torben

Back to comp.compilers | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Thoughts on the JVM as a compilation Target? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-05-22 13:33 -0400
  Re: Thoughts on the JVM as a compilation Target? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-05-24 04:21 +0000
    Re: Thoughts on the JVM as a compilation Target? Jeremy Wright <jeremy.wright@microfocus.com> - 2012-05-24 08:30 +0000
      Re: Thoughts on the JVM as a compilation Target? BGB <cr88192@hotmail.com> - 2012-05-25 14:26 -0500
        Re: Thoughts on the JVM as a compilation Target? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-05-29 17:40 +0200
    Re: Thoughts on the JVM as a compilation Target? "Aaron W. Hsu" <arcfide@sacrideo.us> - 2012-05-24 10:05 -0400
  Re: Thoughts on the JVM as a compilation Target? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-05-24 10:34 +0200
  Re: Thoughts on the JVM as a compilation Target? "lpsantil@gmail.com" <lpsantil@gmail.com> - 2012-05-24 10:39 -0700
  Re: Thoughts on the JVM as a compilation Target? BGB <cr88192@hotmail.com> - 2012-05-24 13:06 -0500

csiph-web