|
Yes, check out the rotor source code here[^]
|
|
|
|
|
Thanks Zoltan,
Interested side. Does the site hacking some Microsoft code to produce the code on web (e.g. de-compile) or they just publish some public avaliable code on web?
regards,
George
|
|
|
|
|
No, it's not decompiled code, it is publicly available source from MS.
link[^]
|
|
|
|
|
Cool, Zoltan!
regards,
George
|
|
|
|
|
Hi George,
Microsoft's Rotor demonstrates a possible implementation of the .NET specs.
There is no guarantee the same code is used in any of the official Microsoft .NET releases.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks Luc!
regards,
George
|
|
|
|
|
Hello everyone,
Two questions about the following code,
1. When instance of Class1 is put to GC queue, its wrapped Obj instance is 100% ensured to move to GC queue, but the order of whether the memory and Finalize method of Class1 instance or obj1 instance will be called first can not be decided (GC may make different decision in different situations)?
2. If some instance does not hold the reference of Class1, but holds the reference to obj1 through public method PassOut, in this situation, Class1 instance is prevent from being GCed?
using System;
public class Class1
{
private Component Obj = new Component();
public Component PassOut()
{
return Obj;
}
public Class1()
{
}
}
thanks in advance,
George
|
|
|
|
|
1. no, the order of freeing objects is well defined.
2. yes, in that case Class1 instance is not garbage collected, because the obj1 reference prevents it.
For more information check this link.[^]
|
|
|
|
|
Hi Zoltan,
Zoltan Balazs wrote: 2. yes, in that case Class1 instance is not garbage collected, because the obj1 reference prevents it.
I don't agree.
obj is an object with two references, one inside Class1 instance, one elsewhere.
if the Class1 object is no longer referenced it is collectable; the obj object does
not prevent that, the only link between Class1 and obj is Class1 contains a reference;
obj lives outside of Class1, so it can have an independent life and it does not need Class1.
Hence, obj stays alive thru the "exported" reference, but the Class1 object is dead.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
modified on Saturday, April 19, 2008 9:11 AM
|
|
|
|
|
You're absolutely right, my mistake!
|
|
|
|
|
Sorry, Luc!
I do not fully agree with you that in order to hold reference to obj1, we have to hold reference to class1.
I give you an example,
1. Class2 instance get reference to class1 and from the reference to class1, get reference to obj1;
2. Class2 passes reference to obj1 only to class3 instance, class3.something = class2.obj1;
3. In this way, class3 only holds reference to obj1, but not class1.
Any comments?
regards,
George
|
|
|
|
|
George_George wrote: I do not fully agree with you that in order to hold reference to obj1, we have to hold reference to class1.
You don't have to, and I can't see anywhere that he said so.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Sorry I miss the context of discussion a bit. The conclusion is obj1 and class1 instances may have
different life time, and no reference to class1 instance does not mean no reference to obj1 instance, right?
2.
Do you think my sample (class1, obj1 and class2) is correct?
regards,
George
|
|
|
|
|
George_George wrote: The conclusion is obj1 and class1 instances may have
different life time, and no reference to class1 instance does not mean no reference to obj1 instance, right?
Yes, the life time of one object is never tied to the life time of another object. They live completely seperate lives, and it's only the active references to each object that determines how long the object is active.
George_George wrote: Do you think my sample (class1, obj1 and class2) is correct?
It's an example of a fairly common situation. It's only the conclusion that is wrong; that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Guffa wrote: It's only the conclusion that is wrong; that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive.
My conclusion is obj1 and class1 instances can have different life time, do you mean my conclusion is wrong?
2.
What do you mean "that a reference to the same object that the Class1 object has a reference to would keep the Class1 object alive."? I am confused when read a couple of times. Could you say in some other words or give some pseudo code please?
regards,
George
|
|
|
|
|
Hi George,
George_George wrote: do not fully agree with you that in order to hold reference to obj1, we have to hold reference to class1.
is the only sentence I don't agree with, since I never said such thing.
objects are independent, they live their own lives; the only way they may interact is
by holding references to each other; a live object obj1 that holds a reference to
object obj2 keeps obj2 alive, not the other way around.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
|
George_George wrote: Any comments
yes, I suggest you use real-life examples rather than class1 and obj2. That often
makes things much more clear. Example:
A car has a couple of wheels, as long as the car is alive the wheels are alive.
But a wheel can exist on its own, just remove it from the car, and scrap the car.
Hence, the car keeps its wheels alive, but the wheel does not keep the car alive.
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Thanks Luc,
I understand your points now. Sorry, I missed your points before.
regards,
George
|
|
|
|
|
Zoltan Balazs wrote: 1. no, the order of freeing objects is well defined.
Where?? I'd like to see your documentation on this. It's well-known that object finalization in .NET is non-deteministic. There is no guaranteed order of object finalization. Here...[^]
|
|
|
|
|
Dave Kreskowiak wrote: It's well-known that object finalization in .NET is non-deteministic.
Yes, I know that.
I was refering to when you have a class and that class has a member. In that case the freeing order is well defined.
As Luc pointed out in the car example, first you free the wheel object and after that the car. Don't you agree with me?
link[^]
"How Finalization Affects Collection
When the garbage collector first encounters an object that is otherwise dead but still needs to be finalized it must abandon its attempt to reclaim the space for that object at that time. The object is instead added to a list of objects needing finalization and, furthermore, the collector must then ensure that all of the pointers within the object remain valid until finalization is complete.
....
Since the internal object pointers must remain valid, not only will the objects directly needing finalization linger in memory but everything the object refers to, directly and indirectly, will also remain in memory. If a huge tree of objects was anchored by a single object that required finalization, then the entire tree would linger, potentially for a long time as we just discussed."
And yes this is for objects that need finalization.
|
|
|
|
|
OK. I thought the original question was the order of finalization. So long as an object as some reference to it, it's kept alive, even if the original object that created it no longer maintains it's own reference to the child object.
|
|
|
|
|
|
Thanks Zoltan,
I think the article only mentions, we need to keep the referred object alive. In my sample, pointer to instance of component1 (of instance of class1), needs to keep alive.
But it never mentions the order of when Finalizer will be called on class1 instance and component1 instance, agree?
regards,
George
|
|
|
|
|
Hi Zoltan,
I read the article you recommended, and it looks great! Cool!
But it does not contain any content about why "the order of freeing objects is well defined". Could you point out which section of the article you refer to please? 
have a good weekend,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
