Re: alternatives to Java byte-codes

Thomas Kistler <>
7 Feb 1999 00:10:04 -0500

          From comp.compilers

Related articles
alternatives to java byte-codes (Juan Alberto de Frutos Velasco) (1999-01-27)
Re: alternatives to java byte-codes (Olivier Lefevre) (1999-01-31)
Re: alternatives to java byte-codes (Niall Dalton) (1999-02-01)
Re: alternatives to java byte-codes dgay@barnowl.CS.Berkeley.EDU (David Gay) (1999-02-03)
Re: alternatives to Java byte-codes (1999-02-05)
Re: alternatives to Java byte-codes (Thomas Kistler) (1999-02-07)
Re: alternatives to Java byte-codes (Paulo Machado) (1999-02-10)
Re: optimization data structures, wasalternatives to Java byte-codes (David Chase) (1999-02-10)
Re: alternatives to java byte-codes (Jesus Cea Avion) (1999-02-10)
Re: alternatives to java byte-codes (Niall Dalton) (1999-02-12)
Re: alternatives to java byte-codes (David Chase) (1999-02-15)
Re: optimizer data structures, was alternatives to Java byte-codes (Bernd Schoeller) (1999-02-15)
| List of all articles for this month |

From: Thomas Kistler <>
Newsgroups: comp.compilers
Date: 7 Feb 1999 00:10:04 -0500
Organization: Compilers Central
References: 99-02-023
Keywords: optimize (Jeremiah S Patterson) wrote:
> AST's are typically hard to optimize
> because (at least this is my experience) it is difficult to come up
> with general optimizations that are not trivial. Byte codes, on the
> other hand, provide a linear (step-by-step) structure rather than a
> tree structure which makes it easy to define "atomic" sections of code
> and optimize those sections.

I strongly have to object. AST are much more convenient for
optimizations since all the high-level information about loops, array
accesses, type information, etc. is available in AST's. However, in
byte-codes all this information gets lost in the translation process
to byte-codes. Therefore it has to be reconstructed from the low-level
structure which can be extremely hard and time-consuming in many
cases. Needless to say that high level information is very important
for aggressive optimizations.

>AST's on the other hand can be easier to generate and interpret.

I have to object again. AST's are not very convenient for interpretation
because AST's usually consume a lot more memory than simple byte-codes.
In many cases in which interpretation is chosen over execution of native
code, memory plays a very important role.

> As far as security goes, it seems like it would be easier to check
> for valid byte strings than valid trees but I haven't tried either, so
> I don't know this for certain.

I'm not an expert in security issues but it seems to me that security
is an orthogonal issue to whether you use byte-codes or AST's. Both of
them can be insecure when not designed appropriately, and both AST's
and byte-codes can be secure if they were designed for it.

> It also seems like it would be easier and more efficient to stream a
> byte code program out over a network. I guess these are more
> advantages for byte codes rather than AST's. This is mostly opinion
> based on experience (which is not exactly years and years).

Here again, streaming is an orthogonal issue to your choice of
intermediate representation. If you transfer a byte-code program in
the order of declaration and the first method invokes the last method
then you have to download the whole class file before you can execute
the program. AST's can very well be designed for streaming. You can
commence execution of an AST if the important sub-trees are transfered

-Thomas Kistler

Post a followup to this message

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