Jv_AllocBytesChecked (Was: What is wrong with Vector?)
Thu Dec 21 16:02:00 GMT 2000
>>>>> "Hans" == Boehm, Hans <email@example.com> writes:
Hans> 1) Delete _Jv_AllocBytesChecked. Replace all calls with calls
Hans> to _Jv_AllocBytes. I assume the compiler does not generate such
Hans> [ rest of plan ]
Hans> This shortens all allocation paths a little, since the collector
Hans> already does out-of-memory checks anyway. (It has to, but there
Hans> it doesn't have to be on the critical path.) It always invokes
Hans> GC_oom_fn when there is not enough memory. It's just that its
Hans> default behavior is to return 0.
This sounds good to me.
One issue though is that this means we'll have to build the GC with
-fexceptions. I don't know whether this has a performance impact or
merely a size impact.
Hans> And my real motivation is that I get the same benefit for
Hans> another allocation function I need for hash synchronization.
I've been meaning to ask you more about this work. Is you change
going to simply put the current mutex structures into a hash table, or
will it also involve moving to more lightweight synchronization
primitives? These two issues seem orthogonal to me. Is there some
I've read that some VMs (Electrical Fire, at least) stack allocate
synchronization objects, at least in the very common case that
monitorenter and monitorexit are paired in a method. How hard do you
think this would be to implement? Do you think it is worth doing?
More information about the Java