RFR: Reduce waste in humongous allocations

[Roman Kennke]

Am Mittwoch, den 14.12.2016, 09:06 +0100 schrieb Roland Westrelin:
> > It's not painful in terms of performance, but painful in terms of
> > implemention. We cannot easily acquire the Heap_lock on allocations
> > because the allocation might come out of a write barrier, and that
> > Java
> > thread is not-in-VM (they call into the VM via a cheap leaf-call).
> > We
> > could change that (and have been there already) to use regular
> > calls
> > like, e.g. allocations do, but this opens up a whole new class of
> > other
> > problems. For example, we need oopmaps at write-barriers which,
> > iirc,
> > presented us some serious optimization problems in C2 land. With
> > Roland's work, those might have gone away though (seems like we can
> > well live with control inputs to write barriers now..)
> 
> If we have a blocking runtime call at a write barrier then
> deoptimization at a a write barrier is possible and we need debug
> info
> at the write barrier. Having debug info and allowing the write
> barrier
> to move around would be quite complicated.

Yeah that's the issues we had last time we tried that.

I am currently working on a different approach: instead of using a
Hotspot Mutex or such, I'm now protecting the allocation code path by a
 little CAS-based spin lock. Kind of like what we already do for
growing the heap, only better :-) It seems to work, only needs some
more testing before I propose it for review.


Stay tuned :-)

Roman