On Tue, 15 Aug 2023 09:51:40 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:
>> Nikita Sakharin has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8314236: change bug number and summary > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/15270#discussion_r1296455894
