Thu Mar 18 21:49:00 GMT 2004
Andrew Haley wrote:
> Perhaps we could have a separate verification pass in gcj -- verify
> first using the libgcj verifier and then do separate semantic
> analysis. That's better than trying to maintain two buggy verifiers.
I agree that would be better to have one verifier than two. And since
I can't afford to maintain the one I wrote on my own time (and I don't
have has much current understanding of the issues as Tom) I won't be
too upset if you choose Tom's. Slightly wistful, as java/gcc/verify.c
is more compact (both source and binary) and possibly more efficient,
though that isn't too relevant if fixing it would require major work.
> I don't think the fact that the libgcj verifier is written in C++ is a
> show stopper. We could have a verifer library and compile it twice,
> once for host and once for target.
If avoiding a dependency of C++ during bootstrapping is desirable,
you can always compile without verification in the first pass - though
I don't think that's a real issue.
Tom Tromey wrote:
> We can just maintain one buggy verifier :-). I won't claim that the
> libgcj verifier is bug-free, just that it uses a model that lets us
> avoid the most common bugs. In particular it does type unions, not
> type merges;
Something I always wanted to do, at least for handling interfaces,
but never got around to.
> and it does subroutine splitting, avoiding the common
> pitfalls and misconceptions around subroutine verification (the
> subroutine problems particularly affect the gcj verifier).
Those were always the hardest problems.
More information about the Java