RFR: JDK-8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out

[Viktor Klang]

On Wed, 22 Mar 2023 13:02:46 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @jaikiran The downside is that it is hard to judge how long it will take for machine X to execute Y instructions. :/
>
> 1. Is there a way to mark this test as skipped if the timeout elapses? I suggest we don't mark it as skipped based on the build or any other configuration, but actaully run it and see if it fails or succeeds. The rationale is this: if the test is still running when the time is out, it means that the test is inconclusive.
> 2. Can we reduce memory configuration to conserve system resources? Say, set `-Xmx` to 96 or even 64 megabytes. Or is so little / unusual that we'll risk getting other issues on modern JVMs?
> 3. I don't see why we need to reduce the number of iterations. What we should do instead is compute it, otherwise that number, whatever it is, looks magic. There needs to be some rationale behing that number, even if that rationale is not accurate. Say, we can reasonably assume that overhead for one `CompletableFuture` is at least one byte. So, to fill up `N` megabyte(s) of heap we would need `N * 1_048_576` iterations.

1. I don't know.
2. It's hard to come up with a one-size-fits-all-heap-size given that differences in pointersizes, object alignment, etc can skew the need.
3. I initially set the threshold (iteration number) at about 4x what I needed locally to make it fail, just to have margin in case memory-usage-per-object would vary with the different setups being tested. 


The other alternative I see would be to reach into the implementation of CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and make sure that it's `getQueue()` eventually goes empty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13116#discussion_r1145069912