=lib Make use of CompletionStage#handle instead of whenComplete

[He-Pin]

Which has better performance.

@lrytz Would you like to give some input, thanks.

Another one was :
line/armeria#1440
line/armeria#1444
akka/akka#31283

I think this will help especially when the CompletionStage was failed already.

[SethTisue]

@viktorklang ?

[He-Pin]

jmh:run -i 5 -wi 5 -f1 -t1 .CompletionStageBenchmark.

package bench

import org.openjdk.jmh.annotations._

import java.util.concurrent.CompletableFuture
import java.util.concurrent.CountDownLatch
import java.util.concurrent.TimeUnit

@State(Scope.Benchmark)
@OutputTimeUnit(TimeUnit.SECONDS)
@BenchmarkMode(Array(Mode.Throughput))
class CompletionStageBenchmark {
  val ex = new RuntimeException("ex")

  @Benchmark
  def benchWhenCompleteFailedSync(): Unit = {
    val future = new CompletableFuture[Int]()
    future.completeExceptionally(ex)
    val latch = new CountDownLatch(1)
    future.whenComplete((_, _) => latch.countDown())
    latch.await()
  }

  @Benchmark
  def benchWhenCompleteSuccessSync(): Unit = {
    val future = new CompletableFuture[Int]()
    future.complete(1)
    val latch = new CountDownLatch(1)
    future.whenComplete((_, _) => latch.countDown())
    latch.await()
  }

  @Benchmark
  def benchHandleFailedSync(): Unit = {
    val future = new CompletableFuture[Int]()
    future.completeExceptionally(ex)
    val latch = new CountDownLatch(1)
    future.handle((_, _) => latch.countDown())
    latch.await()
  }

  @Benchmark
  def benchHandleSuccessSync(): Unit = {
    val future = new CompletableFuture[Int]()
    future.complete(1)
    val latch = new CountDownLatch(1)
    future.handle((_, _) => latch.countDown())
    latch.await()
  }

}

[He-Pin]

I submitted the same to kt too: Kotlin/kotlinx.coroutines#3475

[He-Pin]

[He-Pin]

refs: e3d202e too

[lrytz]

Do you know why handle is faster than whenComplete? Is the performance change significant?

[He-Pin]

Expecially on the failed case, I think the main outcome is from avoiding the encodeThrowable

[lrytz]

Thank you @He-Pin

[nmarton-da]

FYI @He-Pin
JDK 11 has MinimalStage which is a CompletableFuture (also CompletionStage), with UnsupportedOperationException in lot of method bodies (like isDone).
With this change we throw from here at line 73 if encounered a MinimalStage.

I am not claiming this is a bug, or MinimalStage is flawed; neither know whether it is a valid case to have MinimalStage flying around, just letting you know.
Don't shoot the messenger please ;)
Others also implement safety measures: Kotlin/kotlinx.coroutines#2456

[lrytz]

Many thanks @nmarton-da. It reproduces indeed:

scala> import scala.jdk.FutureConverters._
import scala.jdk.FutureConverters._

scala> import java.util.concurrent.CompletableFuture
import java.util.concurrent.CompletableFuture

scala> CompletableFuture.completedStage(42).asScala
java.lang.UnsupportedOperationException
  at java.base/java.util.concurrent.CompletableFuture$MinimalStage.isDone(CompletableFuture.java:2976)
  at scala.jdk.javaapi.FutureConverters$.asScala(FutureConverters.scala:73)
  at scala.jdk.FutureConverters$CompletionStageOps$.asScala$extension(FutureConverters.scala:41)
  ... 30 elided

[lrytz]

It seems play framework had to work around it: playframework/playframework#11993

[He-Pin]

Sorry for the delay, I was busy at shopping festival, will submit fix to other repository this weekend.