RFR: Locked allocation

[Roman Kennke]

Am Donnerstag, den 15.12.2016, 11:44 +0000 schrieb Andrew Haley:
> On 15/12/16 11:31, Roman Kennke wrote:
> > Am Donnerstag, den 15.12.2016, 10:15 +0000 schrieb Andrew Haley:
> > > On 14/12/16 16:36, Roman Kennke wrote:
> > > > When reviewing, please pay special attention to the lock in
> > > > ShenandoahHeap::allocate_memory()!
> > > However, please consider the situation where a thread holding the
> > > lock is descheduled.
> > 
> > Yes. We're doing a SpinPause() when spinning, this should get us
> > back to the thread holding the lock quickly. If you have an idea
> > how to improve this, let me know!
> 
> Please have a look at the way SpinPause() is defined!

I did.

> Maybe it's worth looking at backoff after spinning for a while.  But
> it's very hard to test for consistent behaviour under extreme
> conditions.  Allocating very large objects is quite likely to
> result in page faults, and therefore quite likely to cause a
> thread to be descheduled.  On a heavily loaded system I would
> expect long delays for page faults, while the lock is held.
> 
> I fear that it's very tempting to design Shenandoah so that it
> behaves extremely well when it's not being "abused".
> 
> > gc-bench provides a couple of tests that bash the allocation code
> > with multiple threads, and it did not find performance regressions
> > or bugs.
> 
> Sure, but I'm thinking about systems which are overloaded.  I don't
> know if gc-bench would help there.

I think it's specifically designed to abuse the GC as much as we can.
;-) Aleksey even wrote a test that allocates arrays without
initializing them, cranking out alloc rates in the 100s of GB/sec ...
cannot really do that with ordinary Java code, but should abuse the GC
quite a lot. :-D

And I firmly believe that doing a simple lock around the allocation
code is much more resistent to abuse than the previous implementation,
where multiple threads racing to allocate humongous objects could lock-
step each other, I think it couldn't even guarantee to complete... it's
 much better now I think.

Also, speaking of code smell... the previous lock-free code, well,
'code smell' is not the right word for it ;-) stinking pile of.. well,
you get the idea ;-)


> I presume that you have considered allocating humongous object
> outside
> of Shenandoah's regions altogether.  But even mentioning such a thing
> takes me way outside my area of expertise, so...

yeah... nope ;-)
http://replycandy.com/wp-content/uploads/Godzilla-Nope-Response-Meme.jp
g

(thanks shade for pointing me to the picture ;-) )

Roman