Topic: Where next for C++?- Java-like JIT compiler


Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1997/10/28
Raw View
bparker@mailbox.uq.edu.au (Brian Parker) writes:

|>  IMHO, a very useful complementary standard to standard C++ would be a
|>  standard C++ binary format for Java-like just-in-time compilation on
|>  web download.

I'm not sure that this fits into the charter of C++.  I can see the
utility of such a definition, but I would put it at the level of an API,
defined by a consortium of vendors, and not the standard.  (I certainly
don't want a JIT compiler as part of the run-time in an embedded
processor, for example, even if I need the speed of compiled code.  And
a JIT compiler will never attain the performance of a good static
compiler, which uses the profiling output of a previous run and
optimizes across module boundaries.)

A more interesting move would probably be to find out where the Java
byte code causes problems with C++, and extend it so that C++ can be
reasonably converted.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: bparker@mailbox.uq.edu.au (Brian Parker)
Date: 1997/10/28
Raw View
On 28 Oct 97 07:11:25 GMT, "John Hickin" <hickin@nortel.ca> wrote:
>...
>In fact I think that there would be an excellent opportunity to get
>some really excellent optimizers from such intermediate code: class
>hierarchy anaalysis and type feedback might be very easily implemented,
>with the possibility of turning a large number of virtual function
>calls into inline code.
>...

Yes, according to the documentation from the Juice project their
Oberon backend does a quick poorly optimised compile on initial
download to get the applet/application running quickly, and then they
continue to compile with more advanced optimisations in the
background, and then swap in the optimised code when ready (I don't
really know how they do that).

>  And better yet,
>shared libraries just might treated this way as well, provided that the
>'JIT' optimized code was mapped only into a single process' address space.

A standard format for release-to-release binary compatibility would
allow this- probably based on something like COM on the Windows
platform  (such a standard would also be very useful independently of
the JIT back end).

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: bparker@mailbox.uq.edu.au (Brian Parker)
Date: 1997/10/29
Raw View
On 28 Oct 97 14:29:11 GMT, kanze@gabi-soft.fr (J. Kanze) wrote:

>I'm not sure that this fits into the charter of C++.  I can see the
>utility of such a definition, but I would put it at the level of an API,
>defined by a consortium of vendors, and not the standard.
>...

I agree. I didn't intend that it should be part of the ISO C++
standards process- just offering it as general food for thought.
(actually, comp.lang.c++.moderated may have been a more appropriate
newsgroup).

>...
>A more interesting move would probably be to find out where the Java
>byte code causes problems with C++, and extend it so that C++ can be
>reasonably converted.
>...

That would be interesting, but I'm not sure that interpreted byte
codes are the right approach for desk-top machines that have
sufficient memory to run a compiler immediately on code download- the
speed advantages of C++ would be lost, and the trend nowadays is to
aggressively JIT-compile away the bytecodes anyway.

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: bparker@mailbox.uq.edu.au (Brian Parker)
Date: 1997/10/27
Raw View
IMHO, a very useful complementary standard to standard C++ would be a
standard C++ binary format for Java-like just-in-time compilation on
web download.

To achieve maximum portability, Java was developed on top of an
interpreted virtual machine, but Java implementations are increasingly
including JIT compilers for performance reasons, and code will
increasingly expect their presence. The logical conclusion of this
trend on desktop computers is to simply compile the code on download
and dispense with the interpreted virtual machine- a sort of JIT ANDF.
This approach would be ideal for compile-time intensive languages such
as C++ which aren't easily implemented on an interpreted virtual
machine.

To elaborate, a C++ environment would have a typical front end that
would compile C++ down to a standardised intermediate language format
which would then be JIT-compiled on download by a machine-specific
back end within a browser (or a stand-alone back end). This is, of
course, not a new idea but there is the question of whether the IL
representation would be compact enough and whether the back end would
be fast enough to compile during download. Fortunately, there exists a
proof-of-concept in the form of the Juice project
<http://www.ics.uci.edu/~juice/> which is such a system for the Oberon
language.

Note that most of the implementation complexities of C++, including
header inclusion, template instancing, function overload resolution
and even implicit type conversions would be handled, as usual, by the
front end such that the resultant intermediate language would
represent the parse tree for a simple subset of C++ - essentially just
C with classes and exceptions- that could be quickly compiled by the
back end.

The main disadvantage of a JIT (or rather a "compile-on-download")
compiler compared with an interpreted virtual machine is the security
aspect which would need to be handled by code signing, or a secure
underlying OS.

To be maximally useful, as part of this extension most of the
currently undefined aspects of C++, esp. integer sizes, would need to
be nailed down to create a uniform "network C++" substandard- perhaps
also the presence of a  garbage collector could be required. Also,
standard UI and threading libraries etc would need to be defined (ala
Java).

Other standard extensions that would be complementary to the above
would be a standardised format for separately-compiled templates
(these would only be used by the front end and so wouldn't affect the
design of the back end), and a standard C++ RRBC/DLL format with type
library (ala COM).

Of course, to completely implement the above would be a big task, but
a partial implentation would be also be useful.

Any comments?
Is anyone aware of any current C++ developments in this area?

,Brian Parker.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: "John Hickin" <hickin@nortel.ca>
Date: 1997/10/28
Raw View
It may not be as difficult as you believe.  If my understanding of tools like
Purify and Zero Fault is correct, there are already some proprietary
intermediate representations of code that satisfy your idea of a partial
implementation; the difference here is that these representations are not
limited to C++ code.  Interestingly enough, Zero Fault does seem to have a form
of just-in-time instrumentation (which is the reverse of what you are
proposing) so your idea seems to be quite feasible.

In fact I think that there would be an excellent opportunity to get some really
excellent optimizers from such intermediate code: class hierarchy anaalysis and
type feedback might be very easily implemented, with the possibility of turning
a large number of virtual function calls into inline code.  And better yet,
shared libraries just might treated this way as well, provided that the 'JIT'
optimized code was mapped only into a single process' address space.

--
John Hickin      Nortel Technology, Montreal, Quebec
(514) 765-7924   hickin@nortel.ca
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]