Listing the classes in JDB adds a reference to all the classes in the
program being debugged.

I have come up with a very simple test as below, it requires the JDB command such as "classes", that adds a reference which does not allow the class to be Gced.

Please work with Design.New in the attachment. To compile the sample app open a command prompt, go to the design.new directory created from zip, and type compile.bat. This problem can be reproduced by running the test program run.bat. Then attach to the VM with JDB,

1] hit 1 to load the class in run.bat window,
2] type classes in JDB window, (1 instance of CNdTestClass being loaded)
3] hit 2 to unload the class. (You will notice that no classes are GCed.)

1] hit 1 to load the class in run.bat window,
2] type classes in JDB window, (2 instances of CNdTestClass being loaded)
3] hit 2 to unload the class. (You will notice that no classes are GCed.)

Repeat this cycle... and you will notice that with every cycle, it adds a new
instance of the CNdTest Class in the classes list (of JDB) and the reference
to the class object never gets removed.

The desired behavior should be, that after step 3 of above cycle, the
CNdTestClass should get GCed, and step 2 should leave only one instance of the
CNdTestClass being loaded in the list presented by the command classes in jdb.

There definitely is involvement with some JDB command(s) in regards to the reference being added, as its shown with 'classes'. To verify and prove it, repeat the above cycle test without the step 2. (by that, just attach to the VM by JDB, and without executing the 'classes' command in JDB, load and unload the classes steps 1 and 3 as above, and you should notice that at each cycle CNdTestClass gets GCed.)

You may also want to verify the impact of this problem with the other JDB commands as well.