loom fiber branch doesn't build

[Aleksey Shipilev]

(re-sending from the proper email)

Hi Remi,

On 12/22/18 4:37 PM, Remi Forax wrote:
> Hi all,
> the branch fibers of loom (eeeb45c9ba8e) doesn't build anymore.
> 
> https://travis-ci.org/forax/java-next/jobs/471336518

My CI failed with the same:
 https://builds.shipilev.net/openjdk-loom/openjdk-loom-b33-20181222-jdk-12+24-linux-x86_64-release.build.log

Okay. So, fibers branch has these changes:

 https://builds.shipilev.net/patch-openjdk-loom-fibers/latest/src/hotspot/share/gc/shared/memAllocator.hpp.udiff.html
 https://builds.shipilev.net/patch-openjdk-loom-fibers/latest/src/hotspot/share/gc/shared/memAllocator.cpp.udiff.html

...which come from this changeset:
 http://hg.openjdk.java.net/loom/loom/rev/259c05b297e4

changeset:   51685:259c05b297e4
branch:      cont
parent:      51683:604f34b6c6cf
user:        rbackman
date:        Thu Sep 13 14:21:01 2018 +0200
summary:     Stack and refStack allocation in native

Obviously, after this change, we have to also match the definitions for those changes in Shenandoah,
otherwise, we get:

/home/travis/build/forax/java-next/loom/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp:782:61:
error: no matching function for call to
‘ShenandoahMemAllocator::mem_allocate(MemAllocator::Allocation&) const’
     HeapWord* result = MemAllocator::mem_allocate(allocation);

The minimal fix is:

diff -r eeeb45c9ba8e src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp	Thu Dec 20 13:15:58 2018 +0000
+++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp	Sat Dec 22 17:52:04 2018 +0100
@@ -778,8 +778,8 @@
     _initializer(initializer) {}

 protected:
-  virtual HeapWord* mem_allocate(Allocation& allocation) const {
-    HeapWord* result = MemAllocator::mem_allocate(allocation);
+  virtual HeapWord* mem_allocate(Allocation& allocation, bool try_tlab) const {
+    HeapWord* result = MemAllocator::mem_allocate(allocation, try_tlab);
     // Initialize brooks-pointer
     if (result != NULL) {
       result += ShenandoahBrooksPointer::word_size();

Loom maintainers, please push this where appropriate.

Separately, I _think_ this build failure was not caught during the merge, because Oracle decides not
to build Shenandoah by default, and Alan (or whoever does the actual merge chore at Oracle side)
cannot see the failure in their builds:
  https://twitter.com/shipilev/status/1072210769448706048

-Aleksey