[
https://issues.apache.org/jira/browse/DERBY-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755545#action_12755545
]
Rick Hillegas commented on DERBY-4360:
--------------------------------------
Just a little more information: I instrumented Version.addClassLoader() to
report every time that a class loader was added to the cache of class loaders.
Then I started a run against all trajectories involving the 16 versions of
Derby on my laptop. All of the class loaders were created during the very first
test of the very first trajectory, which tested the upgrade through all of the
versions from first to last. After that, new class loaders were not created for
subsequent trajectories. So the leak isn't caused by inadvertently creating new
class loaders for each test.
Since the class loaders hang around, however, we are slowly accumulating new
generated classes for the queries which verify that the virgin and upgraded
databases are identical. Perhaps this contributes significantly to the leak. A
possible solution might be:
1) Shutdown the engines at the end of very test.
2) After some number of tests, empty the class loader cache so that the vm can
garbage-collect the class loaders along with their accumulating generated
classes.
> Avoid memory exhaustion when running UpgradeTrajectoryTest
> w/-DderbyTesting.allTrajectories=true
> ------------------------------------------------------------------------------------------------
>
> Key: DERBY-4360
> URL: https://issues.apache.org/jira/browse/DERBY-4360
> Project: Derby
> Issue Type: Sub-task
> Components: Test
> Affects Versions: 10.6.0.0
> Environment: JVM:
> Sun Microsystems Inc.
> java version "1.5.0_14"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
> Java HotSpot(TM) Server VM (build 1.5.0_14-b03 mixed mode 32-bit)
> Reporter: Ole Solberg
>
> When run with -XX:MaxPermSize=1024m -Xmx1024m
> -DderbyTesting.allTrajectories=true we get 'Exception in thread "main"
> java.lang.OutOfMemoryError: Java heap space' after ~435 out of 4083
> trajectories.
> When increasing to XX:MaxPermSize=1024m -Xmx2048m we reach ~930 out of 4083
> trajectories,
> without OOM but with extreme upgrade times:
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 ->
> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 ->
> 10.4.2.0 -> 10.5.1.1 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard,
> hard, hard, hard, hard, hard )
> used 10809 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 ->
> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 ->
> 10.4.2.0 -> 10.5.1.1 ( hard, hard, hard, hard, hard, hard, hard, hard, hard,
> hard, hard )
> used 3871 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 ->
> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 ->
> 10.4.2.0 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, hard, hard,
> hard, hard )
> used 3049 ms .
> .
> .
> .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 ->
> 10.3.1.4 ( hard, hard, hard, hard )
> used 95779 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 ->
> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 -> 10.5.3.0 ( hard, hard, hard,
> hard, hard, hard, hard, hard )
> used 167768 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 ->
> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 ( hard, hard, hard, hard, hard,
> hard, hard )
> used 148693 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 ->
> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.3.0 ( hard, hard, hard, hard, hard,
> hard, hard )
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
