Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
[JENKINS-15156] Class loading errors can result from OOME if you are …
…not careful.
  • Loading branch information
jglick committed Feb 7, 2013
1 parent fad1df3 commit 74e6409
Showing 1 changed file with 1 addition and 0 deletions.
1 change: 1 addition & 0 deletions test/src/main/java/org/jvnet/hudson/test/MemoryAssert.java
Expand Up @@ -134,6 +134,7 @@ public static List<HistogramElement> increasedMemory(Callable<Void> callable, Fi
* @param reference object used to verify garbage collection.
*/
public static void assertGC(WeakReference<?> reference) {
assertTrue(true); reference.get(); // preload any needed classes!
Set<Object[]> objects = new HashSet<Object[]>();
while (true) {
try {
Expand Down

1 comment on commit 74e6409

@jglick
Copy link
Member Author

@jglick jglick commented on 74e6409 Feb 7, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johnou was curious about this commit, so for the record:

If you do not do this, it is possible that a concurrent class load will get an OutOfMemoryError (collateral damage), and Java will not try reloading it. So you get NoClassDefFoundErrors on that class henceforth, which can send everything south. I saw this on ComputerSet when I tried to run the test. The original assertGC is smarter because it actually tries to call System.gc and check if the WeakReference is collected before “escalating” the memory pressure to the point of an OutOfMemoryError.

Please sign in to comment.