It is clearly a Good Thing for us to be able to use whatever
high level language we want, and compile it into Java Bytecodes.
Of course, the "memory model" of the chosen language must be
compatible with the JVM. Because the JVM must be secure against
malicious byte codes, it cannot give unrestricted access to memory.
Thus, the obvious C's memory model is out. (You **can**, however,
have a very C like source language, and compile to JVM. Sun had a
"C" to Postscript compiler! Yes, you lose pointer arithmetic, but
you can keep structures and arrays.)
So, to all you JVM experts,
*******************************************
WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?
*******************************************
Let's get the JVM right before the concrete sets!
-- Mark
I guess I'm just old fashioned. My mother always told me that
if you make a boxed value virtual machine, you can run any modern language,
from Basic to Scheme to ML Sather and Modula3 (minus pointer arithmetic).
(I'm tired of having languages forced down my throat. Be honest,
and give me a virtual machine.)
--
==============================================================
Mark Tucker ········@regenstrief.iupui.edu
Regenstrief Institute phone: (317) 630-2606
1001 W. 10'th St; Indianapolis, IN; 46202-2859; fax: (317) 630-6962
In article <·····················@indyvax.iupui.edu> ···@ (mct) writes:
> Newsgroups: comp.lang.java,comp.lang.scheme,comp.lang.lisp,gnu.misc.discuss,comp.lang.misc
> From: ···@ (mct)
> Date: 5 Dec 95 09:21:54 -0500
> Organization: I need to put my ORGANIZATION here.
>
> WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?
From my own experience, as a Scheme VM implementor, there is one thing
that I would lack: the ability to save function environments to the
heap (although I might be biased by my own implementation
technic). What I do is the following:
i) all function environment are built into the stack (as in C),
ii) when a function gets closed, copy the env from the stack to the
heap, and build the closure.
This has some (alot ?) impact on the VM instruction set, although you
could still (as someone mentioned) implement Scheme in Java (have a
look at ftp://koala.inria.fr/pub/abs/java/* for a lisp like language
in Java), but it would not be efficient (ie compete with current
Scheme implementations).
I would like to be able to argue more on the necessity of i) and ii)
although I am afraid the only real argument I have is 'experimental',
so if someone has a better idea, I would like to hear it !
Anselm.
BTW: of course, call/cc would be another problem.
In article <·····················@indyvax.iupui.edu> ···@ (mct) writes:
WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?
I don't know about JVM internals, but if you're thinking of the
broader issue: "What's prevents us from compiling from Scheme or ML to
JVM?", I found an interesting statement in "The Java Language
Environment, A white Paper", from James Gosling and Henry McGilton,
Sun Microsystem, May 1995, section "4.2 Security in the Java
Environment":
What about the concept of a "hostile compiler"? [...] the
code may not have been produced by a known-to-be trustworthy
Java compile. [...] The answer is simple -- [Java run-time
system] doesn't trust the incoming [byte] code, but subjects
it to byte code verification.
The byte code verifier is shortly discribed (1 page) in that paper.
This statement implies that the availability of JVM on the Web is
meant to be restricted by this "byte code verifier", whose role is to
check that you're not trying to use the JVM running on the Web for
anything else than strict Java code. Given the Web market orientation
of Java, this restriction makes a lot of sense.
So you should not think of running you Scheme code as JVM code on the
Web!
Since you cannot use JVM Web implementations to run your Scheme, then
why would you bother compiling Scheme to JVM? Or is there some hope
this restriction can be raised?
Pierre
Pierre Parquier (········@halles.ilog.fr) wrote:
: In article <·····················@indyvax.iupui.edu> ···@ (mct) writes:
: WHAT'S IN THE JVM TO PREVENT US COMPILING FROM SCHEME OR ML?
: I don't know about JVM internals, but if you're thinking of the
: broader issue: "What's prevents us from compiling from Scheme or ML to
: JVM?", I found an interesting statement in "The Java Language
: Environment, A white Paper", from James Gosling and Henry McGilton,
: Sun Microsystem, May 1995, section "4.2 Security in the Java
: Environment":
: What about the concept of a "hostile compiler"? [...] the
: code may not have been produced by a known-to-be trustworthy
: Java compile. [...] The answer is simple -- [Java run-time
: system] doesn't trust the incoming [byte] code, but subjects
: it to byte code verification.
: The byte code verifier is shortly discribed (1 page) in that paper.
: This statement implies that the availability of JVM on the Web is
: meant to be restricted by this "byte code verifier", whose role is to
: check that you're not trying to use the JVM running on the Web for
: anything else than strict Java code. Given the Web market orientation
: of Java, this restriction makes a lot of sense.
I think you're mistaken here. The description of the byte code
verifier (provided below) implies that it wants to make sure that the
bytecode is secure. It doesn't really matter where it comes from.
------------------------------------------------------------------------
From http://java.sun.com/whitePaper/java-whitepaper-8.html#HEADING8-8:
... the Java run-time system doesn't trust the incoming code, but
subjects it to bytecode verification.
The tests range from simple verification that the format of a code
fragment is correct, to passing each code fragment through a simple
theorem prover to establish that it plays by the rules:
it doesn't forge pointers,
it doesn't violate access restrictions,
it accesses objects as what they are (for example, InputStream
objects are always used as InputStreams and never as anything else).
A language that is safe, plus run-time verification of generated code,
establishes a base set of guarantees that interfaces cannot be
violated.
6.2.1 The Byte Code Verifier
The bytecode verifier traverses the bytecodes, constructs the type
state information, and verifies the types of the parameters to all the
bytecode instructions.
[illustration describing separation of bytecode source from bytecode
interpreter omitted]
The illustration shows the flow of data and control from Java language
source code through the Java compiler, to the bytecode verifier and
hence on to the Java interpreter. The important issue is that the Java
bytecode loader and the bytecode verifier make no assumptions about
the primary source of the bytecode stream--the code may have come from
the local system, or it may have travelled halfway around the
planet. The bytecode verifier acts as a sort of gatekeeper: it ensures
that code passed to the Java interpreter is in a fit state to be
executed and can run without fear of breaking the Java interpreter.
Imported code is not allowed to execute by any means until after it
has passed the verifier's tests. Once the verifier is done, a number
of important properties are known:
There are no operand stack overflows or underflows
The types of the parameters of all bytecode instructions are
known to always be correct
Object field accesses are known to be legal--private, public, or
protected
From: Allyn Dimock
Subject: Re: Is the Java VM language-independent or not? Scheme support
Date:
Message-ID: <4a76qn$soe@necco.harvard.edu>
In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the
other Java developers to make sure that the Java VM would support Scheme.
I'm not sure of Steele's exact phrasing, and I may have missed any details
presented during the Q&A period after the official talk.
-- Allyn
········@halles.ilog.fr (Pierre Parquier) writes:
.section "4.2 Security in the Java Environment":
. What about the concept of a "hostile compiler"? [...] the
. code may not have been produced by a known-to-be trustworthy
. Java compile. [...] The answer is simple -- [Java run-time
. system] doesn't trust the incoming [byte] code, but subjects
. it to byte code verification.
>The byte code verifier is shortly discribed (1 page) in that paper.
>This statement implies that the availability of JVM on the Web is
>meant to be restricted by this "byte code verifier", whose role is to
>check that you're not trying to use the JVM running on the Web for
>anything else than strict Java code.
Your conclusion doesn't follow from your argument. The verifier is
testing for violations of the security model. It is not trying to
test whether or not a Java compiler produced the code. There is nothing
to prevent a Scheme compiler from producing byte codes that satisfy
the byte code verifier, simply by making the generated code follow the
rules.
Strong typing can be satisfied by implementing all the Scheme types
as derived classes from a common base class. That's pretty much
all you need.
--
-- Joe Buck <·····@synopsys.com> (not speaking for Synopsys, Inc)
From: Daniel C. Wang
Subject: Re: Is the Java VM language-independent or not? Scheme support
Date:
Message-ID: <YkoksNi00YUuQANd1W@andrew.cmu.edu>
·····@cerc.wvu.edu (Matthew Fuchs) writes:
> ···@best.com wrote:
> : In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimo\
> ck) writes:
> : | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the
> : | other Java developers to make sure that the Java VM would support Scheme.
> : |
>
> : I hope this doesn't mean support for call/cc. Supporting call/cc is
> : nontrivial, and while there is some argument to be made that you want
> : it in a system used for teaching CS and AI/CS research, the tradeoffs
> : for supporting it are just poor for a system like Java.
>
> I disagree entirely. I find call/cc extremely useful. In any case,
> if the Java compiler would use CPS, then call/cc becomes trivial, as
> Andrew Appel has shown with SML/NJ. CPS also makes much more sense in
> a concurrent, distributed environment. Stacks can be really
> clunky in such an environment, especially when IPC really is
> continuation passing. A CPS based Java engine would make life much
> simpler.
hmmm how do you use call/cc in Scheme? The only examples I've seen that
seemed useful were either co-routines or threads, which can be provided with
runtime support.
BTW CPS translation alone doesn't buy you efficient call/cc
implemenetations. SML/NJ does well because "stack" frames/activation records
are all heap allocated and left to the GC to clean up.
From: Matthew Fuchs
Subject: Re: Is the Java VM language-independent or not? Scheme support
Date:
Message-ID: <DJnxwM.5Ms@cerc.wvu.edu>
···@best.com wrote:
: In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimock) writes:
: | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the
: | other Java developers to make sure that the Java VM would support Scheme.
: |
: I hope this doesn't mean support for call/cc. Supporting call/cc is
: nontrivial, and while there is some argument to be made that you want
: it in a system used for teaching CS and AI/CS research, the tradeoffs
: for supporting it are just poor for a system like Java.
I disagree entirely. I find call/cc extremely useful. In any case,
if the Java compiler would use CPS, then call/cc becomes trivial, as
Andrew Appel has shown with SML/NJ. CPS also makes much more sense in
a concurrent, distributed environment. Stacks can be really
clunky in such an environment, especially when IPC really is
continuation passing. A CPS based Java engine would make life much
simpler.
Matthew Fuchs
·····@cerc.wvu.edu
http://www.cerc.wvu.edu/~fuchs
>>>>> "PP" == Pierre Parquier <········@halles.ilog.fr> writes:
PP> What about the concept of a "hostile compiler"? [...]
PP> the code may not have been produced by a known-to-be
PP> trustworthy Java compile. [...] The answer is simple -- [Java
PP> run-time system] doesn't trust the incoming [byte] code, but
PP> subjects it to byte code verification.
[crunch]
PP> This statement implies that the availability of JVM on the Web
PP> is meant to be restricted by this "byte code verifier", whose
PP> role is to check that you're not trying to use the JVM running
PP> on the Web for anything else than strict Java code. Given the
PP> Web market orientation of Java, this restriction makes a lot
PP> of sense.
The statement means that the verifier checks code to be sure
_security_ is not compromised, not that the source code must be Java.
As long as the language you use is as secure as Java (for example, no
pointers) then it can be compiled into Java byte code and executed by
the JVM.
ldd
-- Louis-Dominique Dubeau == ···@step.polymtl.ca == ·····@info.polymtl.ca --
-- Home page: http://step.polymtl.ca/~ldd/
In article <··········@cnn.Princeton.EDU> ···@franck.Princeton.EDU (Tim Hollebeek) writes:
I heard that Java can't handle closures, which I'm not particularly
interested in, but what is the Java equivalent of a function pointer?
Is there such a beast? If not, I can think of several languages that
could be very tough to translate.
I ran into a similar situation with O2C, an Object-C-like language
used for programming the O2 object database. The same functionality
can be achieved by:
Make a making a class containing the function (method) as a virtual method
Create one subclass for each different function you want to pass around
Create one instance of each subclass
The caller passes the subclass instance (rather than a function pointer)
The callee takes the superclass as its argument
--
Peter Ludemann ········@expernet.com
ExperNet phone: +1.408.327.4339
Systems Architect fax: +1.415.949.1395
KNS Project Leader 3945 Freedom Circle,
Suite 240, Santa Clara CA 95054
From: Andreas Krall
Subject: Re: Is the Java VM language-independent or not?
Date:
Message-ID: <4a80ku$88e@news.tuwien.ac.at>
In article <·····················@indyvax.iupui.edu>,
···@ (mct) writes:
>
> It is clearly a Good Thing for us to be able to use whatever
>high level language we want, and compile it into Java Bytecodes.
>
> Of course, the "memory model" of the chosen language must be
>compatible with the JVM. Because the JVM must be secure against
>malicious byte codes, it cannot give unrestricted access to memory.
..
It is much easier than you think. You don't have to worry about the byte
code, just compile C, Lisp, Prolog or your favourite language to Java and
let the Java compiler translate it to byte code. Sometimes it could be
more efficient to directly translate to byte code, but Java compilers
will get better opimization with time. The restrictions will only be
the limits of the byte code definititions
like 32 bit design, 256 local variables and 32k branch offsets, but also
this can only hurt performance.
Andi
--
····@complang.tuwien.ac.at Andreas Krall
http://www.complang.tuwien.ac.at/andi/ Inst. f. Computersprachen, TU Wien
tel: (+431) 58801/4462 Argentinierstr. 8/4/1851
fax: (+431) 5057838 A-1040 Wien AUSTRIA EUROPE
In article <·····················@expernet26.expernet.com> ········@expernet26.expernet.com (Peter Ludemann) writes:
[to make a function pointer equivalent in java]...
Make a making a class containing the function (method) as a
virtual method
Create one subclass for each different function you want to
pass around Create one instance of each subclass
The caller passes the subclass instance (rather than a
function pointer)
The callee takes the superclass as its argument
and if you add instance variables to the sub-class, you have a
closure.
--
For my papers and software, look at
http://crl.nmsu.edu/users/CRLfolks/dunning.html
···@crl.nmsu.edu (Ted Dunning) wrote:
>and if you add instance variables to the sub-class, you have a
>closure.
I'm sorry to be dense, but could you elaborate? I think of a closure as
binding the environment in which it is created.
Bob
From: Tim Hollebeek
Subject: Re: Is the Java VM language-independent or not?
Date:
Message-ID: <4a87p9$ctt@cnn.Princeton.EDU>
In article <··········@news.tuwien.ac.at>,
Andreas Krall <····@complang.tuwien.ac.at> wrote:
>In article <·····················@indyvax.iupui.edu>,
> ···@ (mct) writes:
>>
>> It is clearly a Good Thing for us to be able to use whatever
>>high level language we want, and compile it into Java Bytecodes.
>>
>> Of course, the "memory model" of the chosen language must be
>>compatible with the JVM. Because the JVM must be secure against
>>malicious byte codes, it cannot give unrestricted access to memory.
>..
>It is much easier than you think. You don't have to worry about the byte
>code, just compile C, Lisp, Prolog or your favourite language to Java and
>let the Java compiler translate it to byte code. Sometimes it could be
>more efficient to directly translate to byte code, but Java compilers
>will get better opimization with time. The restrictions will only be
>the limits of the byte code definititions
>like 32 bit design, 256 local variables and 32k branch offsets, but also
>this can only hurt performance.
I heard that Java can't handle closures, which I'm not particularly
interested in, but what is the Java equivalent of a function pointer?
Is there such a beast? If not, I can think of several languages that
could be very tough to translate.
--
Tim Hollebeek | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ. | ···@wfn-shop.princeton.edu
-------------------| http://wfn-shop.princeton.edu/~tim
Tim Hollebeek (···@franck.Princeton.EDU) wrote:
: I heard that Java can't handle closures, which I'm not particularly
: interested in, but what is the Java equivalent of a function pointer?
: Is there such a beast? If not, I can think of several languages that
: could be very tough to translate.
Can't you just create an interface that contains one static method which
has the signature of the function you want a pointer to? A pointer to
the function is just implemented as a pointer to an object that has a
class that implements this interface. Seems OK to me. The object can be
a subclass of Object.
Similarly you should be able to implement functions (as opposed to
methods) by creating a subclass of Object that implements the function
as a static method.
If you want a closure instead of a function pointer, you can just
introduce private members into the class you are using, and have the
method call the actual function with the correct parameters.
Am I overlooking some problem here?
--
Erik Corry ·······@inet.uni-c.dk
In article <··········@cloner3.netcom.com> Bob Foster
<······@ix.netcom.com> writes:
>···@crl.nmsu.edu (Ted Dunning) wrote:
>>and if you add instance variables to the sub-class, you have a
>>closure.
>
>I'm sorry to be dense, but could you elaborate? I think of a closure as
>binding the environment in which it is created.
That's the meaning at the programming language level, but if you're
looking at implementing closures in some abstract machine (whether
that be Java itself or the Java VM) all you need ability to package up
a finite set of environment values with a reference to a function in
question. The assertion isn't that Java, as a language, has closures,
but that it has the components needed to make the translation fairly
easy (or at least as easy as the substitute for function pointers
mentioned earlier). Your translator can translate, say
(...
(set! f (lambda (y) (x + y + z)))
...
(f 3)
...)
into (in something somewhere between Java and C++):
{
class closure_1 : public function_object {
protected: Object mx; Object mz;
public: closure_1(x, z) { mx = x; mz = z; }
public: Object call_this(y) { return mx + y + mz; }
}
...
f = new closure_1(x, z);
...
f.call_this(3)
...
}
-David
--
============================================================================
David Wald http://theory.lcs.mit.edu/~wald/ ····@theory.lcs.mit.edu
============================================================================
····@theory.lcs.mit.edu (David Wald) wrote:
>In article <··········@cloner3.netcom.com> Bob Foster
><······@ix.netcom.com> writes:
>>···@crl.nmsu.edu (Ted Dunning) wrote:
>>>and if you add instance variables to the sub-class, you have a
>>>closure.
>>
>>I'm sorry to be dense, but could you elaborate? I think of a closure as
>>binding the environment in which it is created.
>
>That's the meaning at the programming language level, but if you're
>looking at implementing closures in some abstract machine (whether
>that be Java itself or the Java VM) all you need ability to package up
>a finite set of environment values with a reference to a function in
>question. [snip]
>{
> class closure_1 : public function_object {
> protected: Object mx; Object mz;
> public: closure_1(x, z) { mx = x; mz = z; }
> public: Object call_this(y) { return mx + y + mz; }
> }
>
> ...
> f = new closure_1(x, z);
> ...
> f.call_this(3)
Gosh, thanks. Excellent example. A couple of comments: It doesn't work
in the sense of binding to the calling environment when x and z are
primitive values, not objects. This applies recursively with respect to
values referred to by x and y. And it doesn't work in general in C++,
because the references to x and z may no longer be valid when
call_this() is called.
Java seems to provide the minimal confluence of features (all objects
are heap objects, automatic garbage collection) to enable closures in a
practical sense. In C++, a "closure class" would be burdened with
too many caveats.
Bob
From: Fernando D. Mato Mira
Subject: Secure Scheme (was: Is the Java VM language-independent or not?)
Date:
Message-ID: <4ahrf8$92d@info.epfl.ch>
BTW, check also:
http://www.inria.fr/koala/abaird/oscheme/secure.html
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
Hhhhmmmmm...
Fernando D. Mato Mira wrote:
>
> BTW, check also:
>
> http://www.inria.fr/koala/abaird/oscheme/secure.html
I did this. Nice information, but where do I get OScheme from?
--
------- ·····@rheged.dircon.co.uk (Simon Brooke)
...but have you *seen* the size of the world wide spider?
From: Fernando D. Mato Mira
Subject: Re: Secure Scheme (was: Is the Java VM language-independent or not?)
Date:
Message-ID: <4bp5pl$nu4@info.epfl.ch>
In article <·················@rheged.dircon.co.uk>, Simon Brooke <·····@rheged.dircon.co.uk> writes:
|> > http://www.inria.fr/koala/abaird/oscheme/secure.html
|>
|> I did this. Nice information, but where do I get OScheme from?
http://www.inria.fr/koala/abaird/oscheme/get.html
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
Computer Graphics Lab
Swiss Federal Institute of Technology (EPFL) Phone : +41 (21) 693 - 5248
CH-1015 Lausanne FAX : +41 (21) 693 - 5328
Switzerland E-mail : ········@di.epfl.ch
Bob Foster (······@ix.netcom.com) wrote:
: ····@theory.lcs.mit.edu (David Wald) wrote:
: > {
: > class closure_1 : public function_object {
: > protected: Object mx; Object mz;
: > public: closure_1(x, z) { mx = x; mz = z; }
: > public: Object call_this(y) { return mx + y + mz; }
: > }
: >
: > ...
: > f = new closure_1(x, z);
: > ...
: > f.call_this(3)
:
: Gosh, thanks. Excellent example. A couple of comments: It doesn't work
: in the sense of binding to the calling environment when x and z are
: primitive values, not objects.
You can get around this fairly simply, but putting the primitive
values in a container class. These classes are already predefined
in Java.
: This applies recursively with respect to values referred to by x and y.
Does it? You can't have a reference to a primitive type, so
you must mean primitive values that are members of x and y.
But that would seem to me to work.
--
Erik Corry ·······@inet.uni-c.dk
>>>>> "objfac" == Bob Foster <······@ix.netcom.com> writes:
In article <··········@cloner3.netcom.com> Bob Foster <······@ix.netcom.com> writes:
objfac> ···@crl.nmsu.edu (Ted Dunning) wrote:
>> and if you add instance variables to the sub-class, you have a
>> closure.
objfac> I'm sorry to be dense, but could you elaborate? I think of a closure as
objfac> binding the environment in which it is created.
Closure is <private data> + <code accessing that data>, from
implementational point of view. And so is instance.
See, e.g.
@techreport( 76Lambda,
author = {Guy Lewis Steele Jr.},
title = {Lambda, the Ultimate Declarative},
year = 1976,
month = nov,
number = 379,
type = {MIT AI Memo},
institution = {Massachusetts Institute of Technology},
address = {Cambridge, Mass.},
keywords = {declarative} )
in the section "Actors \equiv Closures (mod Syntax)".
--mad
From: Guillermo (Bill) J. Rozas
Subject: Re: Is the Java VM language-independent or not? Scheme support
Date:
Message-ID: <GJR.95Dec14134636@hplgr2.hpl.hp.com>
In article <···············@tmb.vip.best.com> ···@best.com () writes:
| Reply-To: ···@best.com
| In-reply-to: ······@das.harvard.edu's message of 7 Dec 1995 17:04:23 GMT
| X-Newsreader: Gnus v5.0.4
|
| In article <··········@necco.harvard.edu> ······@das.harvard.edu (Allyn Dimock) writes:
| | In a talk at MIT on Dec 6, Guy Steele said that he had a mandate from the
| | other Java developers to make sure that the Java VM would support Scheme.
| |
| | I'm not sure of Steele's exact phrasing, and I may have missed any details
| | presented during the Q&A period after the official talk.
|
| I hope this doesn't mean support for call/cc. Supporting call/cc is
| nontrivial, and while there is some argument to be made that you want
| it in a system used for teaching CS and AI/CS research, the tradeoffs
| for supporting it are just poor for a system like Java. I also hope
| it doesn't mean Scheme's floating point stuff, which not even MIT
| bothers to implement.
Hah? In the context ot a simple VM like Java's, supporting cwcc is
straight-forward. Even with compilation it is not hard.
The hard issues have to do with inter-operability with C, since C code
is typically not reentrant in this fashion.
With respect to floating point, what do you mean that MIT does not
implement it? There is really no floating-point in the Scheme
standard/reports. Floating-point is an implementation technique for
numbers that the standard works well with. As far as I know MIT's
implementation is fully compliant with the standard and uses
floating-point to represent some classes of numbers. MIT's is not the
only implementation with this property.
| Beyond that, there really is nothing that the Java VM needs to support
| Scheme reasonably well.
Tail recursion?
From: ········@millcomm.com
Subject: Re: Is the Java VM language-independent or not?
Date:
Message-ID: <4ar483$8d8@misery.millcomm.com>
In <···············@tmb.vip.best.com>, ···@best.com () writes:
>In article <·····················@halles.ilog.fr> ········@halles.ilog.fr (Pierre Parquier) writes:
>| What about the concept of a "hostile compiler"? [...] the
>| code may not have been produced by a known-to-be trustworthy
>| Java compile. [...] The answer is simple -- [Java run-time
>| system] doesn't trust the incoming [byte] code, but subjects
>| it to byte code verification.
>|
>| The byte code verifier is shortly discribed (1 page) in that paper.
>|
>| This statement implies that the availability of JVM on the Web is
>| meant to be restricted by this "byte code verifier", whose role is to
>| check that you're not trying to use the JVM running on the Web for
>| anything else than strict Java code. Given the Web market orientation
>| of Java, this restriction makes a lot of sense.
>|
>| So you should not think of running you Scheme code as JVM code on the
>| Web!
>|
>| Since you cannot use JVM Web implementations to run your Scheme, then
>| why would you bother compiling Scheme to JVM? Or is there some hope
>| this restriction can be raised?
>
>You completely misunderstood the passage. The byte code verifier is
>simply a type checker at the byte code level. It doesn't care whether
>the source was written in Java, Scheme, or assembly, as long as the
>byte code is type correct.
>
>There is no restriction to be raised.
I haven't had a chance to take a close look at Java yet, and have not even had
a glimpse at the JVM definition, but in many ways it sounds similar to the IBM
AS/400 MI concept, and thus there are probably some things that can be learned
about the JVM concept by looking at the AS/400.
AS/400 has two basic MI (virtual Machine Interface) models. The older, cruder
one is a storage-to-storage model, while the newer one is a stack model
distantly related to P-code. In both models a "trusted translator" is used to
convert the MI code stream into an executable code stream, eliminating the
need for most storage protection mechanisms, etc. This has worked quite well
(in conjunction with a "capability" pointer mechanism) though recently
hardware storage protection mechanisms have been added (largely to satisfy the
auditors passing on certification for the military C2 security
classification). This "trusted translator" concept is not much different from
the concept of a trusted interpreter -- in both cases checks are made to
assure that the input stream can't do things it shouldn't.
One other point about the AS/400 MI (both versions) is that it incorporates a
call-return stack model and associated exception mechanisms. I get the
impression that the JVM model does likewise, though that's just reading
between the lines of the posts here. I think the built-in call-return support
is a good idea, even though it may cramp the style of some programmers.
I can't articulate what it does for you, but I sense that it enables a finer
grain of "filtering" -- making it possible to allow more accessible function
while maintaining a given degree of protection of the system.
Dan Hicks
A Christmas gift: http://www.millcomm.com/~danhicks/Christmas.html