Jv_AllocBytesChecked

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

My apologies for sending this out with the wrong subject:

> -----Original Message-----
> From: Boehm, Hans [mailto:hans_boehm@hp.com]
> Sent: Thursday, December 21, 2000 3:21 PM
> To: 'java-discuss@sources.redhat.com'
> Subject: RE: What is wrong with Vector?
> 
> 
> 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
>