> This test intentionally allocates ~256 MB packed ints ... the seed > doesn't fail in isolation, but I think the test fails if it's run with > other tests that leave too much uncollectible stuff allocated in the > heap ...
It doesn't need to be hard refs. With parallel garbage collectors (with various staged memory pools) and fast allocation rate a thread may fail with an OOM even if there is theoretically enough space for a new allocated block. Running with SerialGC typically fixes the problem but then -- this isn't realistic :) > Can we somehow mark that a test should be run in isolation (it's own > new JVM)...? Technically this is possible I think (can't tell how large refactoring it woudl be). But something in me objects to this idea. On the one hand this is ideal test isolation; on the other hand I bet with time all tests would just require a forked VM "because it's simpler this way". Good tests should clean up after themselves. I'm idealistic but I believe tests should be fixed if they don't follow this rule. > Another option ... would be to ignore the OOME ... but the risk there > is we suppress a "real" OOME from a sudden bug in the packed ints. > Though it's unlikely such a breakage would escape our usages of packed > ints... so maybe it's fine. How close are we to the memory limit if run in isolation (as a stand-alone test case)? We can probably measure this by allocating a byte[] before the test and doing binary search on its size depending on if it OOMs or not? Maybe it's just really close to the memory limit? Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
