Re: Note on BC and type assertions

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:

> Tom Tromey writes:
> > While browsing the verifier again, I noticed that there is a dynamic
> > constraint that we can't represent using our current type
> > assertions, namely:
> > 
> > 	    if (type_isarray (&t) || type_isinterface (&t) \
> > 		|| type_isabstract (&t))
> > 	      verify_fail ("type is array, interface, or abstract");
> > 
> > We could put this check in _Jv_AllocObject (the worst option IMO), add
> > a new kind of verification assertion, or write a BC-only wrapper for
> > _Jv_AllocObject that does this check.
>  
I think type_isarray() can be determined statically by its name - it 
shouldn't be possible to replace an array type with something that is 
not an array type at runtime. Yes, I agree we need assertions for the 
others.

> > There may be other assertion types we need to handle as well, a pass
> > through the verifier looking for them is warranted.
>
> That's why I wanted to generate code for the assertions.  Then you can
> assert anything you want.
>  
Using a table of bytecodes with up to 2 utf8 operands we could assert 
pretty much anything we wanted. The number of conditions that we 
actually need to assert should be relatively small, anyhow - I think 
that giving the runtime more flexibility in how/when it wants to process 
the assertions is better than allowing the compiler to emit anything it 
wants, but losing control over when the assertions get run, how the 
operands are loaded/linked, etc.

Bryce