Jv_AllocBytesChecked

Thu Dec 21 15:23:00 GMT 2000

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
>