Does value type object cannot be collected by GC (Garbage collector)?

Question

0.00/5 (No votes)

See more:

I was reading an article in which one class has three variable declaration.

2 of type INT and 1 of type string in a class (all private variables)

In that article it was written one the control pass reach to the end of method both int type variable scope will end aromatically but for string type variable GC will check it is not referred by any instance of program then GC will collect it?

Does this mean GC won't handle value type object if yes then how these are managed?

Posted 12-Nov-14 3:11am

Sudhir Dutt Rawat

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

BillWoodruff · Answer 1 · 2014-11-12T03:45:00

Solution 2

I'm confused: you describe a Class with three variables; one is a string. Then you talk about a Method. The variables' scope will depend on where they are created: in the Class' scope, or in a method in the Class' scope.

Strings are a special case: every one you create through defining at design-time/code-time, or at run-time, is interned: put in a special CLR table called the "intern pool." The reason for that is to make all strings with the same content have only one reference point, so look-up, and comparison, can be very fast.

Interned strings become part of the Assembly itself, and are not garbage collected.

See: [^], [^].

In general it would be an exceptional use case that would need for the programmer to directly manipulate what is in the intern pool, or the interned status of a given string in your application.

In most cases programs that create too many strings (by concatenation, for example) can be re-factored to use the 'StringBuilder object.

Posted 12-Nov-14 3:45am

BillWoodruff

Comments

PIEBALDconsult 12-Nov-14 9:51am

"every one you create through defining at design-time/code-time, or at run-time, is interned:"

That is not what the documentation you point to says.

BillWoodruff 12-Nov-14 12:00pm

Thanks for the feedback, Piebald !

Reading this in the second link, and remembering similar content read elsewhere:

"The common language runtime conserves string storage by maintaining a table, called the intern pool, that contains a single reference to each unique literal string declared or created programmatically in your program. Consequently, an instance of a literal string with a particular value only exists once in the system."

I thought I was on "safe ground" in what I wrote. Can you give me a clue to what you are referring to ?

PIEBALDconsult 12-Nov-14 12:11pm

Not all strings are interned; literals are, but other strings are not unless the developer specifically requests it.

BillWoodruff 12-Nov-14 12:20pm

Thanks, that definitely contradicts the assumptions about string handling in .NET I've developed, but correcting assumptions is a most valuable thing to do. I'm a little burned-out right now, but tomorrow will re-visit what Anders, Skeet, Lippert, Troelsen, etc. have said in various .NET books, and re-think, and if needed correct this post, or remove it.

Sudhir Dutt Rawat 12-Nov-14 10:19am

Correction - The variables are declared in the method not the class. Sorry for that misunderstanding.

Sergey Alexandrovich Kryukov 12-Nov-14 11:48am

Those variables are on stack, and the referenced objects are still in heap. If you don't carry out a reference to a calling context (method return, ref/out parameters), the variable referenced go out of scope and hence become inaccessible. This is the criterion for GC to destroy them, eventually. As Bill correctly posted, strings is a special thing due to interning.
—SA

Sergey Alexandrovich Kryukov 12-Nov-14 11:45am

5ed. By some (rather apparent) reasons, interning is poorly understood feature. :-)
—SA

PIEBALDconsult 12-Nov-14 12:14pm

Nor does it need to be understood.

BillWoodruff 12-Nov-14 12:21pm

Perhaps not needed, but I think it's good to know.

Sergey Alexandrovich Kryukov 12-Nov-14 12:24pm

The thesis "does not need to be understood" makes some sense but can lead us way to far...
—SA

PIEBALDconsult · Answer 2 · 2014-11-12T03:28:00

Solution 1

Non-reference types can't be referenced from multiple places, ergo the GC needn't check for more references before deallocating the memory.

Sudhir Dutt Rawat wrote:
scope will end aromatically

:laugh: :laugh: :laugh: :laugh:

Posted 12-Nov-14 3:28am

PIEBALDconsult

Updated 12-Nov-14 3:29am

v2

Comments

Sergey Alexandrovich Kryukov 12-Nov-14 11:44am

That's correct, but a developer should take into account that a value type can have reference-type members; and each of such members can be referenced in different places.
Also, OP mentioned the strings, which are the subject of string interning. Strings are not used as other reference objects, they are reused in an intern pool.
—SA

PIEBALDconsult 12-Nov-14 11:48am

Yeah, so?
Actually a developer needn't care about any of that.

Sergey Alexandrovich Kryukov 12-Nov-14 12:26pm

Do you know about the memory leaks even in the memory-manages systems? This opens the way to create memory leaks.
—SA