On Wed, 22 Mar 2023 16:29:21 GMT, Pavel Rappo <pra...@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