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

[Viktor Klang]

On Wed, 22 Mar 2023 16:29:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> 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.
>
>> 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.
> 
> From what I've seen, JDK prefers blackbox tests to whitebox tests. Even though the latter might conserve resources better and are easier to implement, they are problematic in the long run: they become an obstacle if the system under tests is modified.

@pavelrappo I agree with that. I have the same experience. With that said, I have implemented a whitebox test which reaches in an monitors the task queue of the Delayer. @AlanBateman & @jaikiran any preference here?

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

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