AppDomains and GC

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Jon Shemitz - 15 May 2005 22:36 GMT

I am under the impression that all user-created AppDomain-s in a
process share the GC heap with the default AppDomain - they don't
share values, but they do share the mechanism and address space. Is
this correct?

Signature

www.midnightbeach.com

Reply to this Message

Alvin Bruney [MVP - ASP.NET] - 23 May 2005 17:37 GMT

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/d
otnetgcbasics.asp

Signature

Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc

>I am under the impression that all user-created AppDomain-s in a
> process share the GC heap with the default AppDomain - they don't
> share values, but they do share the mechanism and address space. Is
> this correct?

Reply to this Message

Jon Shemitz - 23 May 2005 19:49 GMT

> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/d
otnetgcbasics.asp

Thank you - but while that's a very nice GC Basics article, it doesn't
seem to address my question at all? I read through, and it didn't say
anything about app domains ... searches for both "AppDomain" and
"domain" came up blank.

> > I am under the impression that all user-created AppDomain-s in a
> > process share the GC heap with the default AppDomain - they don't
> > share values, but they do share the mechanism and address space. Is
> > this correct?

Signature

www.midnightbeach.com

Reply to this Message

Alvin Bruney [MVP - ASP.NET] - 26 May 2005 02:50 GMT

>I am under the impression that all user-created AppDomain-s in a
> process share the GC heap with the default AppDomain

Yes.

- they don't

> share values, but they do share the mechanism and address space. Is
> this correct?

The addressing mechanism, but not the address space. Each has its own
specific address boundary. When the CLR COM server is loaded into a windows
process, it creates a managed heap. The managed heap is global to the
windows process. App domains - to include the default app domain - have
evidence and versioning applied so that they are completely isolated from
each other. Each app domain has its own loader heap which is basically a
boundary for its types. They can only cross this boundary in a well defined
way. So they do not share the address space.

This picture is slightly complicated by the server version of the CLR
execution engine running MSCorsvr.dll. In this instance, though there is
only one heap, it is segmented on a per CPU basis so that each CPU contains
its own segment. I think the correct term is arenas and not segment from the
MS docs.

You can also have more arenas inside the central heap on a machine running
the workstation version (none server). This is specifically setup for the
large object heap that service allocations over 85kbytes.

hope this helps

Signature

Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc

>
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/d
otnetgcbasics.asp
[quoted text clipped - 8 lines]
>> > share values, but they do share the mechanism and address space. Is
>> > this correct?

Reply to this Message

Jon Shemitz - 26 May 2005 20:19 GMT

> The managed heap is global to the windows process.

The managed heap holds memory our code allocates, right? So, a string
owned by the default AppDomain may exist on the managed heap right
next to an ArrayList owned by the "Secondary" AppDomain?

> Each app domain has its own loader heap which is basically a
> boundary for its types. They can only cross this boundary in a well defined
> way. So they do not share the address space.

Well, yes, but the loader heap is where types and jitted code go - the
stuff that gets unloaded with an AppDomain. The loader heap is a
traditional heap, not garbage collected.

I'm only asking about garbage collected app data.

Signature

www.midnightbeach.com

Reply to this Message

Alvin Bruney [MVP - ASP.NET] - 29 May 2005 04:50 GMT

that's not a good way of looking at it because the run-time does not make
that kind of guarantee. it just *may be possible that this could actually
happen but the two objects would be separated by an app domain boundary so
they aren't really *next to each other* in a real sense.

put another way, you are asking whether the continent of africa and america
are next to each other. well yes they technically are, but there is a big
wide ocean between them so they really aren't next to each other in a real
sense

are you wondering if an app domain value can be mistakenly read by another
app domain? that can't happen anymore. that sort of failure is only common
in unmanaged code because the memory model is weaker.

Signature

Regards,
Alvin Bruney - ASP.NET MVP

[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
Now available @ www.lulu.com/owc, Amazon.com etc

>
>> The managed heap is global to the windows process.
[quoted text clipped - 13 lines]
>
> I'm only asking about garbage collected app data.

Reply to this Message

Jon Shemitz - 29 May 2005 05:12 GMT

> that's not a good way of looking at it because the run-time does not make
> that kind of guarantee. it just *may be possible that this could actually
[quoted text clipped - 9 lines]
> app domain? that can't happen anymore. that sort of failure is only common
> in unmanaged code because the memory model is weaker.

No, I'm not worried about type safety. I trust .NET there.

I'm just not sure about the implementation issue, whether it's one
pool or many. Whether allocation in "this" appdomain can trigger gc
for "that" AppDomain.

Everything I read implies one pool, but I don't think anything
actually says so. (I wouldn't be surprised to learn that it depends on
single vs multi processor, or total memory size.)

Signature

www.midnightbeach.com

Reply to this Message

AppDomains and GC

Free Magazines