lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dawid Weiss <>
Subject Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure
Date Thu, 31 May 2012 21:16:07 GMT
> 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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message