Also, more investigation is required in order to figure out why the test passes with insane jars but fails
(due to OOM) with sane jars. At the very least, some kind of logic would be necessary to only run the test for insane
builds, and I have no idea how (or if) that logic would work in JUnit.
I don't think anyone has ever done performance and/or memory profiling
work against a "sane" system. Effort is probably best spent elsewhere.
Having said that, I have done the following kinds of changes to ASSERT
code in the past.
The first thing that comes to mind is the nature of the Strings in
the various Sanity checks. In the past I have searched the code for
ASSERTS which "build" strings like the following, I have not done it
recently:
if (SanityManager.DEBUG)
SanityManager.ASSERT(x == 0,
"Incorrect offset. offset = " +
getRecordOffset(slot) +
", offset should be < " +
"(PAGE_HEADER_OFFSET + PAGE_HEADER_SIZE) = " +
(PAGE_HEADER_OFFSET + PAGE_HEADER_SIZE) +
", current slot = " + slot +
", total slotsInUse = " + slotsInUse);
It is preferred that it be written as:
if (SanityManager.DEBUG)
{
if (x != 0)
{
SanityManager.THROWASSERT("Incorrect offset." + ...
}
}
The first instance can require the jvm to build the full string every
execution, even when the assert does not fire. The second will only
build the string in the error case. The first definitely slows down
the sane system, and I assume increases memory usage.
