RE: Bytecode safety
At 06:44 PM 9/18/2001 -0700, Hong Zhang wrote: Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. We can use similar model as Java bytecode. Because of poor design, the Java bytecode requires exponential algorithm to verify the bytecode, mainly caused by weak-typing on local variables (where all other parts of Java runtime are strongly typed), and the notorious jsr/ret bytecode. We should avoid the same kind of mistakes. The bytecode verification should be about O(n * ln(n)). Given how weakly typed so much of Perl (and thus Parrot) is, I'm not sure that there's much we can do to verify externally. The best I can think of is to have the dangerous ops validate their parameters and the oploop do resource checks as appropriate. :( I may, however, be suffering from a lack of imagination. That'd be OK. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Bytecode safety
I would vote no. HOWEVER, I would think that the user should have the option to turn on checking for malformed bytecode (i.e. Safe mode). In the default case, I think the bytecode should be assumed well formed and no extra checking be performed. -Original Message- From: Damien Neil To: [EMAIL PROTECTED] Sent: 9/18/2001 4:37 PM Subject: Bytecode safety Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? - Damien
Re: Bytecode safety
On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. Haven't we done this argument? :) I'd vote no, FWIW. -- Dames lie about anything - just for practice. -Raymond Chandler
Re: Bytecode safety
On Tue, Sep 18, 2001 at 10:40:30PM +0100, Simon Cozens wrote: On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. Haven't we done this argument? :) Sort of, while talking about other things. I wanted to drag it out to stand on its own. : - Damien
Re: Bytecode safety
On Tue, 18 Sep 2001, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. I don't see this as a safety issue. There's nothing unsafe about crashing. It's just not as pretty as putting up a big ol' YOUR BYTECODE IS SNOOKERED message. Having that message is not worth even a 1% degradation in runtime speed. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Sounds great, but make it a separate program that gets run optionally with the default being to not run it. Validating variable-length instructions takes non-trival time and having it outside the normal execution path will allow to indulge in whatever costly-code analysis you desire. -sam
Re: Bytecode safety
Gibbs Tanton - tgibbs [EMAIL PROTECTED] writes: I would vote no. HOWEVER, I would think that the user should have the option to turn on checking for malformed bytecode (i.e. Safe mode). In the default case, I think the bytecode should be assumed well formed and no extra checking be performed. Something akin to gcc's --enable-checking strikes me as a really good idea. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Bytecode safety
At 02:37 PM 9/18/2001 -0700, Damien Neil wrote: Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. Yes, no? Yes and no. The default dispatch loop shouldn't check. The Safe dispatch loop (note the caps there... :) should check. Checking is more than just a plain safety issue. There are resource checks, different jump op functions, and a variety of disabled or paranoid things in there. It's a non-trivial problem, but it is one that we should, and must, address at some point. I hadn't planned on doing it so soon, but if someone's so inclined, that'd be great. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Bytecode safety
Proposed: Parrot should never crash due to malformed bytecode. When choosing between execution speed and bytecode safety, safety should always win. Careful op design and possibly a validation pass before execution will hopefully keep the speed penalty to a minimum. We can use similar model as Java bytecode. Because of poor design, the Java bytecode requires exponential algorithm to verify the bytecode, mainly caused by weak-typing on local variables (where all other parts of Java runtime are strongly typed), and the notorious jsr/ret bytecode. We should avoid the same kind of mistakes. The bytecode verification should be about O(n * ln(n)). Hong
