At 10:30 AM -0800 2/26/02, Hong Zhang wrote:
> > >That's (potentially) an awfully big table. But maybe I'm missing the
>point.
>> >If we're not trusting the bytecode to be safe, and this table is part of
>the
>> >bytecode, how do we know the table is safe?
>>
>> We vet the table at load time to make sure it's safe. That way we
>> avoid the cost of checking that the destination is valid for every
>> opcode branch and jump. Otherwise we need to check that the
>> destination of a branch is actually an opcode. (To avoid jumping into
>> data and suchlike things)
>
>The jump target table can be generated by linear scan the bytecode. So there
>is no real benefit for including it in the class file, otherwise we have to
>verify the table itself, which is another linear algorithm (at least).
Good point. If we can't trust the bytecode, it's not like we can
trust the valid jump table anyway.
>The KVM of Java includes pre-verify info, which serves similar purpose. The
>reason behind is Java bytecode verification is (kind of) NP-complete. By
>using
>pre-verify info, the problem can be reduced to linear in most case. (No one
>prove it mathmatically, but you got the idea.)
Hmmm. Can you trust it? Seems like it wouldn't help drop the time,
since you'd need to verify the pre-verify info, though I suppose
verifying the information might be faster than constructing it from
the bytecode.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
