> Brent Fulgham wrote:
> > The first (i.e., most recent) paper discusses several flaws
> > with existing JVM's.
>
> I probably won't have time to go through all these papers.
> But, I will certainly be available to answer any question you
> have about SableVM's internal representation, and how you can
> make use of it.
>
Oh, absolutely. I hope I am not offending you by sending all
this mail. I just want to "enter them into the record" so to
speak, so we have them archived in the mailing list, since I
can't always find things once I need them.
> > I think it would be great if we could
> > provide a work-around on top of SableVM.
>
> I am open to extentions, as long as they can be truned off/on easily
> (compile and/or run time, if there's no efficiency penalty).
> Preferably, extentions should be off by default, so that users using
> SableVM as a normal Java interpreter get what they expect.
>
Yes. It is critical that the JVM be fully Java-compliant, otherwise
it is relatively useless.
> Note: You might also want to start thinking about the implications of
> adding closures on the verifier... I know that many functional
> languages provide static safety, but the Java interpreter
> also provides compiler independent link time safety through the
> verifier, a protection against devious compilers.
>
Hmm. This is a good point with respect to providing compilers with
access to some internal JVM state to implement, e.g., continuations.
One that I haven't though about...
> > It might not be standard, but perhaps (if it is successful) it
> > could be added to the JVM specification?
>
> This is not under my control (it is under Sun's), but I can certainly
> allow you to test your ideas with SableVM:-)
>
Excellent! Some of these papers seem to indicate that certain performance
benefits might be realized by Java itself through the proposed constructs.
Only benchmarking will say for sure. But it might be interesting to try
them (if we can do so in a safe fashion).
Thanks,
-Brent
|
