Ah, quite right. For the archives, to confirm this for myself, I wrote
a little C# code:
using System;
class Class1
{
static int x = 0;
[LoaderOptimizationAttribute(LoaderOptimization.SingleDomain)]
static void Main(string[] args)
{
x += 5;
}
}
With SingleDomain, this JIT compiles to (stack cleanup code removed for
brevity):
x += 5;
00000000 push ebp
00000001 mov ebp,esp
00000003 push eax
00000004 mov dword ptr [ebp-4],ecx
00000007 add dword ptr ds:[003E50ECh],5
}
And with MultiDomain, this compiles to:
x += 5;
00000000 push ebp
00000001 mov ebp,esp
00000003 sub esp,8
00000006 mov dword ptr [ebp-4],ecx
00000009 mov ecx,59Ch
0000000e call FD5B0DE8
00000013 mov ecx,59Ch
00000018 mov dword ptr [ebp-8],eax
0000001b call FD5B0DE8
00000020 mov edx,dword ptr [eax]
00000022 add edx,5
00000025 mov eax,dword ptr [ebp-8]
00000028 mov dword ptr [eax],edx
You can clearly see the indirection in the MultiDomain case, as
expected.
Thanks Mike!
Greg Reinacker
Reinacker & Associates, Inc.
http://www.rassoc.com
-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]] On Behalf Of Mike Woodring
Sent: Tuesday, June 04, 2002 7:17 AM
To: [EMAIL PROTECTED]
Subject: Re: Singleton pattern
Actually, the LoaderOptimization flag controls how the JIT-compiled code
for
types is handled. But it won't affect the observable nature of having
types
loaded separately into each appdomain from the standpoint of a developer
and
their expectations with respect to the scope of static fields. The
storage
for static fields is always allocated on a per-appdomain basis. Using
the
LoaderOptimization attribute does not change that. It does change
whether
the code for types is JIT-compiled once per-process or once
per-appdomain.
Code that accesses statics is therefore JIT-compiled differently based
on
that setting (per-process code has to use a level of indirection to
"find"
and access the static variables for the appdomain the code is running in
at
any moment in time; while code that access statics and compiler
per-appdomain can be JITed with a direct reference to the variable).
-Mike
http://staff.develop.com/woodring
http://www.develop.com/devresources
----- Original Message -----
From: "Greg Reinacker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 03, 2002 5:09 PM
Subject: Re: [ADVANCED-DOTNET] Singleton pattern
> > Don't you automatically get one
> > instance of a static class in each app-domain?
>
> This behavior depends on the LoaderOptimization setting, which is set
> when an AppDomain is created (either at AppDomain.CreateDomain, or
> CorBindToRuntimeHost).
>
> Greg Reinacker
> Reinacker & Associates, Inc.
> http://www.rassoc.com
>
>
> -----Original Message-----
> From: Moderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED]] On Behalf Of Shawn
> Wildermuth
> Sent: Sunday, June 02, 2002 12:24 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Singleton pattern
>
>
> I've been using static classes for singleton's. Is this a bad
approach?
> Are static constructor's unreliable? Don't you automatically get one
> instance of a static class in each app-domain? Maybe that's the
> issue...
>
> Thanks,
>
> Shawn Wildermuth
> [EMAIL PROTECTED]
>
> > -----Original Message-----
> > From: Moderated discussion of advanced .NET topics.
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Noam Arbel
> > Sent: Saturday, June 01, 2002 12:39 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [ADVANCED-DOTNET] Singleton pattern
> >
> >
> > I think it is usefull to understand when SuppressFinalize()
> > should be used. If you look at code like this:
> >
> > public class UseResource
> > {
> > public void OpenResource()
> > {
> > // open a resource for use
> > }
> >
> > public void UseResource()
> > {
> > // Do some stuff with the resource
> > }
> >
> > public void CloseResource()
> > {
> > // close the resource
> > SuppressFinalize(); // <== make sure Finalize is not called
> > }
> >
> > ~UseResource()
> > {
> > // close the resource
> > }
> >
> >
> > A good coder will open the resource, use it multiple times
> > and call the
> > CloseResource() at the end (hopefully in a finally block).
> > This will call the SuppressFinalize() letting the GC know
> > that cleanup has been done.
> >
> > But if the user did not call the CloseResource explicitly, it
> > will get closed through the destructor and not left dangling.
> >
> > As to the public constructor on the Singelton class, it does
> > look strange.
> >
> > Noam
> >
> > You can read messages from the Advanced DOTNET archive,
> > unsubscribe from Advanced DOTNET, or subscribe to other
> > DevelopMentor lists at http://discuss.develop.com.
> >
>
> You can read messages from the Advanced DOTNET archive, unsubscribe
from
> Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the Advanced DOTNET archive, unsubscribe
from
Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
