• 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
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Is String Instance Variable, ever GC Eligible?

 
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Given a code like above: I was wondering as lines 9 through 11 get executed, do the instance variable name and array[] become GC eligible at the same time as the Rectangle objects? Thanks
 
Master Rancher
Posts: 3313
31
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The int[] arrays do, yes.  The Strings that are referenced by "name" would become eligible - except that in this case, because you used String literals (or more generally, compile-time constants of type String) those same String objects are referenced by the String pool.  Which makes them not eligible for GC.

In general, String instance variable certainly can refer to variables which can become eligible for GC.  But there must also be no other reference to the string in question.  So if the String was read from user input, or otherwise created dynamically, that might be eligible.  But String constants are never eligible, because of the String pool
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So had it not been for the constructor initializing the name with passed literals, then name would not have been referenced by the String pool and would have been GC eligible like the array[]. Is this the mechanics of it? Thanks
 
Mike Simmons
Master Rancher
Posts: 3313
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Exactly.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great. So following the same logic, had another String instance variable were present, i.e. String lastname; then this one would have been GC eligible, like the array[]?
 
Mike Simmons
Master Rancher
Posts: 3313
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes - provided, again, that lastName is not populated using a String constant.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That cleared it up a lot. Thanks Mike.

You know it just hit me. Any of the rules would have changed if the String name, lastname; and int array[]; were instance variables of a different class, than the one that instantiations were executed in its main()?  
 
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please always tell us where such questions come from, to avoid copyright problems and to enable us to verify the original if necessary.
What are the rules determining whether the int[] is or isn't reachable? There might be a String pool, but there is no such thing as an int[] pool. The rules are not going to change if the field is in another class. Note, in your example, array always points to null and there is no int[] object to be reachable or not reachable.
If you have String literals (or other compile‑time constant Strings), they are regarded as “reachable” until the class(es) they are declared in are unloaded from memory. Remember that String literals in any type (class/interface/enum) are only loaded into memory when that type is used.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right, very poor choice of array name (using a java key word). But thanks to Mike and you, now I've got String GC subject locked.  
 
Mike Simmons
Master Rancher
Posts: 3313
31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Since the two fields are public and non-final (), it's entirely possible they could be set to some non-null value if this class is invoked from some other class. Usually we frown on public fields though; I'm surprised you didn't get a lecture from Campbell. ;) . Of course if there's other code involved beyond what's shown here, then that other code may have additional references to the String or int[] objects, which might prevent GC of those objects even if a given Rectangle is eligible.  GC questions get complicated when we imagine other code beyond what's shown.
 
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I may be nitpicking here but I feel like there's a basic misunderstanding just based on the language used. Call it semantics but a variable is never GC'd. Objects are GC'd. It's technically incorrect to say that an instance variable will ever be GC'd because instance variables are simply references to objects (unless they're primitive types). It's the objects that they reference that may be eligible to be GC'd if you set the instance variables to null and no other reachable reference to the same object exists.

In the given code, two Rectangle objects are created, each one passed in a reference to a String value, which just happens to be a String literal. The name instance variables of the Rectangle objects assigned to local variables one and two reference the String literals "g1" and "g2", respectively. On lines 10 and 11, the Rectangle objects that were created on line 7 and 8 become GC eligible. However, the String object referenced by the name instance variable of either Rectangle never becomes GC eligible because, as MS said, they are in the String Pool and those don't GC'd.

I don't believe it's correct to say that the int[] array instance variable will ever be eligible for GC either because again, reference variables do not get GC'd. Nothing in the code ever assigns an array object to that instance variable either so there's nothing to GC.

If the code had included these lines:

then after one is set to null, the int[] {1, 2, 3} that is referenced by the one.array instance variable will no longer be reachable, therefore it will be eligible for GC.

Again, it's the objects that become GC eligible, not the references to them.

Just want to make sure you understood the distinction.
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a different example to illustrate some of the points I made previously:


Since Java 11, you can do this:
$ java Foo.java bar

On line 3, you create a String object that is not in the String pool. That String object will be referenced by the bar local variable.
On line 5, you pass bar to the Rectangle constructor and instantiate a Rectangle object whose name instance variable references the same String object that bar references.
On line 6, you create another Rectangle object whose name instance variable again references the same String object.

At this point, there are three reachable references to the same String object: bar, one.name, and two.name.

On line 8, you set bar to null. There are now only two reachable references left that reference the same String object: one.name, and two.name
On line 9, you set one to null. Now, while one.name still references the same String object (you never set it to null), it is no longer reachable through one.name.
So you only have one reachable reference to the same String object ("foo" + args[0]): two.name
On line 10, you set two to null. Again, two.name still references that String object but it's no longer reachable.

Only at this point do you have 0 reachable references to the String object created on line 3 and only then is it eligible for GC.

Again, it's the object that becomes GC-eligible, not the reference variables.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks everyone for your input. That clears up things a lot. As for the code, I just wrote a quick code on this editor to ask about GC. That's why the some viewed things got in:)

By the way let me ask, what would have been GC status of the object "lastname", if the reference "one" was not set to null? Thanks
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
lastname is not an object, it is an object reference variable. As I tried to explain before, variables don't get GC'd. You have to understand the distinction between reference variables and the objects themselves. Only objects are eligible for GC
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jake Monhan wrote:So had it not been for the constructor initializing the name with passed literals, then name would not have been referenced by the String pool and would have been GC eligible like the array[]. Is this the mechanics of it?


That is actually not the mechanics of it.

The String literals "g1" and "g2" are interned in the String Pool. When you pass the literal to the Rectangle constructor, the name field of the Rectangle object that is being instantiated is made to reference that String object. So it's wrong to say that "name is referenced by the String pool." It is, in fact, the other way around: a String object that just happens to be in the String pool is referenced by the name field of the Rectangle that was instantiated.

Even if you set the name field to null, that String object will not be GD'd due to the fact that it is in the String Pool. And even if you set name to null, name itself does not get GC'd because it is a reference variable, not an object. This distinction is important to understand.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:lastname is not an object, it is an object reference variable. As I tried to explain before, variables don't get GC'd. You have to understand the distinction between reference variables and the objects themselves. Only objects are eligible for GC



I believe that was my underlying confusion, compounded by String pool vs. Strings on the heap. Thanks for details.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I emember correctly, and I might not, the Sting pool is part of the heap.
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, but it is an exclusive heap area open to String VIP's only

Also since the nitpicking this subject has been very beneficial, let me ask a broader question.

If the following code were to be added to either set of above codes,

Double dgc1 = new Double(5.0); //line 1
Double dgc2 = 5.0; // line 2

Am I correct in stating that line 2 has nothing to do with GC consideration, while the object in line 1 does? Thanks



 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please don't hi‑jack threads by asking new questions; please make that question into a mew thread.
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As far as I know, String is the only type that has special handling by the JVM for performance. Small Integer values also are cached but you should not rely on that behavior.

The second line will autobox the double literal in a Double object which would be eligible for GC once any references to it become unreacheable.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . . Small Integer values also are cached but you should not rely on that behavior. . . .

. . . but it is specified in the JLS, and the Integer#valueOf(int) documentation.
 
Junilu Lacar
Sheriff
Posts: 13675
226
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Documentation also says "may cache other values outside this range" but doesn't specify anything else. So again, I would not write any code that depends on the caching behavior. For that matter, optimizations like the String constant pool and the caching of small integers is nice to know but shouldn't be anything you rely on unless you're trying to squeeze every last bit of memory and performance as you can.
 
Campbell Ritchie
Marshal
Posts: 65365
248
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You mean they are things you know about for the cert. exam and are allowed to forget 0.1sec afterwards? I would be happy with that notion
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's why I chose the Double variable example to keep the -128 to 127 caching range out of this GC discussion.
As for the cert. exam. I still think a lot of the designers for those exams, also design the DMV written exams
 
Marshal
Posts: 7070
491
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jake Monhan,

CowGratulations, your topic has been published in our CodeRanch Journal August Edition.

A copy of journal you could find here -> https://coderanch.com/wiki/715405/CodeRanch-Journal-August
Other than that, you, as everybody else supposed to get one emailed to you
 
Jake Monhan
Ranch Hand
Posts: 103
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you.

I guess my old high school physics teacher was right when he told me, "in science there is no such thing as a dumb question."
 
You get good luck from rubbing the belly of a tiny ad:
create, convert, edit or print DOC and DOCX in Java
https://products.aspose.com/words/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!