Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 7 May 2012 12:15:49 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1802564056.34032.1336392949557.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1644724966.2121.1335516958132.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5730) DataDictionaryImpl leaks references
 to itself via SYSFUN_AD
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269563#comment-13269563 ] 

Knut Anders Hatlen commented on DERBY-5730:
-------------------------------------------

> Can you comment on expected performance degredation now that we are
> caching less, I don't know what work the caching is saving. Since we
> are still caching privately I think only expected degredation is on
> first call for booted db, though I know there are some applications
> out there that boot very often.

That's right, degradation should only be expected on the first call of
a SYSFUN function after the second db boot.

I'm not sure what degradation to expect myself, so I've written a
small test program that executes the following statement repeatedly:

  values atan(tan(asin(sin(acos(cos(pi()))))))

The statement calls seven different SYSFUN functions, and I would
expect it to be very close to the worst case since VALUES statements
are among the cheapest ones to compile.

I also turned off the statement cache, so that each execution of the
statement would cause a compilation (it is during the bind phase of
the compilation the SYSFUN_AD array is accessed).

Using the test program, I compared clean trunk to a variant that was
modified to skip the caching altogether. That is, I commented out the
following line in DataDictionaryImpl.getRoutineList():

          DataDictionaryImpl.SYSFUN_AD[f] = ad;

The variant that didn't cache the alias descriptor, executed the
statement 2.5% slower on average in my environment.

Since this degradation will only be observed when SYSFUN functions are
compiled for the first time in newly booted databases, I'd say it's
negligible.

One might perhaps even say that the gains of the alias descriptor
cache are so small that they don't justify the extra memory and code
complexity, but I don't think we want to go there in this JIRA.

> If there were no memory consequences does the existing
> implementation have any correctness issues?

Not that I have been able to find. The data dictionary instance is
only used in the following situations, as far as I can tell:

- At initialization time of the AliasDescriptor to find the UUID of
  the SYSFUN schema. This doesn't cause any problems, since the data
  dictionary instance is still alive at that time, and the UUID of the
  SYSFUN schema is the same in all databases.

- When an alias is dropped, but the functions in SYSFUN can't be
  dropped.

- During invalidation, but SYSFUN functions can't be invalidated.
                
> DataDictionaryImpl leaks references to itself via SYSFUN_AD
> -----------------------------------------------------------
>
>                 Key: DERBY-5730
>                 URL: https://issues.apache.org/jira/browse/DERBY-5730
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.9.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: Sysfun.java, d5730-1a.diff
>
>
> DataDictionaryImpl contains a static field called SYSFUN_AD, which holds an array of AliasDescriptor objects for the functions in the SYSFUN schema. This array is lazily populated as the functions are called, and it is shared between all DataDictionaryImpl instances on the system.
> The AliasDescriptors contain references to the DataDictionaryImpl that created them, so SYSFUN_AD may end up referencing indirectly to a number of different DataDictionaryImpl instances, depending on where the respective SYSFUN functions are called the first time. Once an AliasDescriptor has been added to SYSFUN_AD, it stays there until the DataDictionaryImpl class is unloaded (in most cases, until the JVM terminates). This means the array may hold references to DataDictionaryImpl instances that belong to database instances that have been shut down, and that the memory held by those database instances never becomes eligible for garbage collection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira