• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Unexpected GC Behavior

Ranch Hand
Posts: 1865
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's something interesting. It appears that the compiler does some unexpected optimizations that become apparent when the finalizer method announces the finalization of each instance. The following code example behaves as expected. The first four instances of class J are finalized but the last instance is not finalized. The output of the program is 0123 and then the wait method waits forever because the last instance is not finalized and the J.notFinalized method never returns zero.
As long as the local variable j in method m1 is initialized to null before the "for" loop is entered then the scope of variable j remains the entire body of method m1. However, the compiler appears to have the option to reduce the scope of variable j.
If j is not initialized before the loop and if j is not used after the loop then the scope of j is reduced to only the body of the loop. After control passes out of the loop then any object referenced by j is eligible for finalization and garbage collection. As a result, all five instances of class J become eligible for garbage collection when the loop is completed and all five instances are finalized and method m1 returns and the program runs to completion. The output is 01234.
Is this behavior well known or was I the only one that did not realize that optimization can reduce the scope of a local variable?

Go ahead and run this code example. The output should be 0123 before the program waits forever for the last instance to be finalized. Then run the program again with the initialization of j removed. The scope of j will then be reduced to the body of the loop and all five instances of j will be finalized.
It is important to remember that the real exam only tests behavior that is defined in the JLS. Undefined optimizations are not required knowledge. At this point, I'm not suggesting that this behavior is required knowledge. I just think it's interesting.
[ October 20, 2002: Message edited by: Dan Chisholm ]
Author and all-around good cowpoke
Posts: 13078
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I ran into the same thing with one of the mock questions I wrote. I thought that as long as the variable was in scope, it would not be GCed, in spite of the fact that execution could not possibly return to the code using the variable. Somebody objected to it so we tried some experiments.
As I recall, the JDK 1.0 level compiler/runtime would not GC as long as the thread was in the method but later versions apparently could recognize that the variable could be GCed. A big surprise to me.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic