[jira] Commented: (DERBY-3612) Developer's Guide needs correction on garbage collection

["Martin Zaun (JIRA)" <ji...@apache.org>]

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

Martin Zaun commented on DERBY-3612:
------------------------------------


Hi Kim,

while your changes on the garbage collection invocation and options are all correct and look good to me, I've developed doubts that the described underlying problem really is one: that the class EmbeddedDriver needs to unloaded or Derby can't be restarted in the same VM again.

To be sure, I've seen such static initialization issues before, and in the appserver we treated them as a bug and fixed them (if I remember correctly).

But I'm not sure if Derby indeed has this problem -- at least, I was unable to reproduce it.

Here's what I tried: 
1) run ij with JVM options -Xnoclassgc (and -verbosegc)
2) connect 'jdbc:derby:testdb';
3) select * from test;
4) connect 'jdbc:derby:;shutdown=true';
5) repeat steps 2-4 x times

No errors except the expected "ERROR XJ015: Derby system shutdown." message.  Also tried the network case with -Xnoclassgc on the client and server side to be sure; again no errors.

I also tried with a different JDBC client by basically modifying the Derby demo's SimpleApp to load the driver and shutting down the engine multiple times:

    public static void main(String[] args)
    {
        new SimpleApp().go(args);
        new SimpleApp().go(args);
        new SimpleApp().go(args);
        System.out.println("SimpleApp finished");
    }

Again, no problems.

All these tests makes me doubt the following statement in the documentation:

>>> To restart Derby successfully, the JVM needs to unload org.apache.derby.jdbc.EmbeddedDriver, so that it can reload it when it restarts Derby. (Loading the local driver starts Derby.) <<<

and definitely proves wrong another statement:

>>> Running with the non-standard option -Xnoclassgc definitely prevents the class from being unloaded and makes you unable to restart Derby in the same JVM. <<<

It would be good if someone who's been much longer involved with Derby than I have a look at this:

- Was there, perhaps, a class initialization issue in the past that's been fixed?  If so, the entire two paragraphs in the documentation should be deleted.

- Or was the issue of a different kind than my test tried to reproduce?  If so, some more information on the problematic use case in the documentation would be helpful, since this is what the user needs to avoid; my simple test case above, which fits the current description, turns out not to be problematic, even with -Xnoclassgc.

Martin

> Developer's Guide needs correction on garbage collection
> --------------------------------------------------------
>
>                 Key: DERBY-3612
>                 URL: https://issues.apache.org/jira/browse/DERBY-3612
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.3.2.1
>            Reporter: Kim Haase
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-3612.diff, tdevdvlp20349.html
>
>
> In a comment on DERBY-3585, Martin Zaun pointed out the following error:
> devguide/tdevdvlp20349.dita
>    - found a flatly wrong statement but did NOT correct here since
>      unrelated to server shutdown authentication:
>      "You cannot explicitly request that the JVM unload a class, but you
>      can ensure that the EmbeddedDriver class is unloaded by using a
>      System.gc() to force it to garbage collect classes that are no longer
>      needed. Running with -nogc or -noclassgc definitely prevents the class
>      from being unloaded and makes you unable to restart Derby in the same
>      JVM."
>      System.gc() is only a suggestion to the Runtime to garbage-collect, it
>      cannot be enforced, and there's no guarantee whatsoever that GC has
>      run and any classes been unloaded. Likewise it's most probably not
>      guarantueed that -nogc or -noclassgc definitely (!) prevent a class
>      from being unloaded (a JVM may ignore these options...) 
> This needs to be fixed. Thanks, Martin.
> One more question: are -nogc and -noclassgc java command line options, or options to some other command? I can't find them in the java command documentation -- http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html. There is an -Xnoclassgc option, however.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.