RE: What is wrong with Vector?

["Boehm, Hans" <hans_boehm at hp dot com>]

I'm contemplating a low level change in the libgcj runtime, and I'd like to
make sure I'm not overlooking some negative consequences.  I would like to

1) Delete _Jv_AllocBytesChecked.  Replace all calls with calls to
_Jv_AllocBytes.  I assume the compiler does not generate such calls?

2) Similarly delete all explicit checks on a 0 return from any of the
garbage collecting allocators (but not from the system malloc).

3) Export a function from prims.cc that just does a _Jv_Throw(no_memory);

4) Set GC_oom_fn to point to a C function that calls the above as part of
the GC initialization code.

5) Fix up nogc.cc so that it does the necessary checking.

This shortens all allocation paths a little, since the collector already
does out-of-memory checks anyway.  (It has to, but there it doesn't have to
be on the critical path.)  It always invokes GC_oom_fn when there is not
enough memory.  It's just that its default behavior is to return 0.

It removes one function call from the _Jv_AllocBytes path, which I hope will
shortly become more important.  (Another function call should go away if we
introduce GC-specific headers.)  And my real motivation is that I get the
same benefit for another allocation function I need for hash
synchronization.  That one can also turn out to be on a critical path,
though only when things go wrong.

It should also eventually allow us to collapse the _Jv_AllocObject path,
once the compiler special cases objects without finalizers.

Hans