On Wed, 16 Aug 2023 21:38:09 GMT, Stuart Marks <sma...@openjdk.org> wrote:
>> test/jdk/java/util/Collections/RotateHuge.java line 27: >> >>> 25: * @test >>> 26: * @bug 8314236 >>> 27: * @summary Overflow in Collections.rotate >> >> Since this test takes >4G of heap to hold the list with compressed oops, and >> >8G of heap without compressed oops, we need to run it in a separate VM with >> enough headroom, something like this: >> >> >> * @test >> * @bug 8314236 >> * @summary Overflow in Collections.rotate >> * @requires (sun.arch.data.model == "64" & os.maxMemory >= 16g) >> * @run main/othervm -Xmx12g RotateHuge > > @nikita-sakharin > > Thanks for finding this bug and offering to fix it! (And @shipilev thanks for > your assistance on this.) > > Putting the test into a separate JVM will work, but I don't think it's > necessary to actually allocate the space. The test is only testing the > indexes sent to `get` and `set` on the list, and it doesn't actually verify > the contents of the list. (Presumably that's done by other tests.) Therefore > it should be possible to create a "virtual" list of a given size that checks > that the indexes are all in bounds but that doesn't actually store any > elements. It should be fairly straightforward to do this by subclassing > AbstractList and overriding a few methods. > > The advantage of not actually allocating 4G of memory is that it makes it > easier to run a bunch of cases that test the boundary conditions. In fact I'd > like to see that in the test, as opposed to testing this one case. Oh yes, let's do the synthetic `AbstractList` (?) subclass, instead of allocating lots of memory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1297030276
