On Wed, 22 Mar 2023 13:02:46 GMT, Pavel Rappo <pra...@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
