db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-1315) Statement optimization/compilation fails with OutOfMemoryException in largeCodeGen test with embedded and framework DerbyNetClient
Date Thu, 31 Aug 2006 20:20:11 GMT


> 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.


Mime
View raw message