• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

strong reference  RSS feed

 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A m() { return new A(); }
Is a strong reference always an explicitly declared variable
A a = m();
or can a strong reference be a location on the stack not necessarily associated with a source code variable declaration
m();
// at this point a reference to an A object may exist on the stack
[ August 05, 2003: Message edited by: Marlene Miller ]
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I believe that, unless the object is reachable via some handle (or series of handles), that it is eligible for garbage collection. Therefore, an object sitting on the stack that is not referenced by any variable is not strongly referenced.
Take a look at this article for lots of good info on Java's Reference Object API.
I hope that answers your question.
Corey
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ummm... is there a context in which it would make a difference? If we call an anonymous stack reference a "strong reference", are there any meaningful statements whose truth or falsity would be significantly affected? If we're talking about whether the A instance is eligible for collection - well, it's probably not eligible while it's being constructed, but it is eligible immediately thereafter. Whether it is collected or not is an implementation detail we can't answer reliably anyway. Does that help?
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Corey and Jim for your help and ideas.

When m3() is invoked, I assume the A object is reachable at least until line 10.
I use to think, an object is reachable if there is a chain of references to the object starting from a declared local variable or class variable. This example tells me I am wrong.

is there a context in which it would make a difference?


Not that I know of.
Just this, �An object enters the unreachable state when no more strong references to it exist. When an object is unreachable, it is a candidate for collection.�
I trying to correct my view of strong reference, so that I can apply it to the example above. Where is the GC root?
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim, you changed your sentence at the end, again.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think I can answer my own questions, now.
I have just learned that when a method returns, the object reference is popped from the operand stack of the current frame and pushed onto the operand stack of the frame of the invoker.
The thread stack is part of the GC roots. Since the operand stack is part of the thread stack, the operand stack is *probably* part of the GC roots. As long as the object reference is on some operand stack, it is *probably* reachable.
Until line 10. in the example above, the object reference in on some operand stack. So the A object is reachable.
The answer to my first question is *probably* no, a strong reference does not have to be an explicitly declared variable.
[ August 06, 2003: Message edited by: Marlene Miller ]
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim, you changed your sentence at the end, again.
Yeah, I do that now and then to keep people on their toes. Glad you noticed.
I think it may be worthwhile to note that if you're considering whether an object is considered "reachable", the concept of "reachable" was defined in JLS 12.6.1 which includes the following:
"Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable."
So right away there seems to be an acknowledgement that the definition of what's really "reachable" can be a little fuzzy depending on compiler and JVM implementation details. Personally I'm not inclined to spend too much time worrying about exactly where the border of "reachable" lies; I'm content to just consider the effects of those references that appear explicitly in the source code.
By the way, if you haven't already done so, you should check out Douglas Dunn's http://www.javarules.com/ and the earlier volume available here. (Note the appallingly cheap used copies.) The books function very well as companions to the JLS for those of us who like to go in-depth at figuring out what the JLS really meant. I think you'd get some value from them; I did. (Well I just got the free download of the second volume; I'm assuming it's comparable to the first.) Neither one seems to have anything about threads or GC, the topics I most often see you posting about lately - but if you still find yourself looking at some of the other sections of the JLS, these are worth looking at. Here are the contents of the first volume if you're interested. And if we support the author, he may eventually cover threads, etc. in volume 3.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you once again, Jim, for your views and all the good references, to the JLS and Douglas Dunn�s books.
I once started to read in Java Rules about <clinit> and <init>. I see those when using the Forte debugger. I wondered how he knows about them. Is he describing one particular implementation of the JVM? Do you think he has read the JVM source code or is he deducing the information from observations in some IDE?
(I always thought the man playing the sax on the cover of Java Rules was Douglas Dunn. I guess not.)
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I once started to read in Java Rules about <clinit> and <init>. I see those when using the Forte debugger. I wondered how he knows about them. Is he describing one particular implementation of the JVM? Do you think he has read the JVM source code or is he deducing the information from observations in some IDE?
Those are defined in the JVM Spec, section 3.9. I don't know if that's where Dunn first learned of them. You can see them in any stack trace that's thrown from a class or instance initializer. (Or constructor or initialization expression; it's all the same as far as the JVM is concerned). It's nothing specific to a particular JDK or IDE.
(I always thought the man playing the sax on the cover of Java Rules was Douglas Dunn. I guess not.)
Hah! Me too. Well, I actually saw somewhere what he really looked like; then I forgot, and subconsciously kept thinking of the author as a black saxophone player.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for showing me where clinit is defined. I was a little lazy. I never looked there.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!