Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <malic...@mac.com>
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Delivered-To: moderator for perl6-intern...@perl.org
Delivered-To: perl6-intern...@perl.org
Date: Thu, 1 Jan 2004 18:23:56 -0500
Mime-Version: 1.0 (Apple Message framework v482)
Content-Type: multipart/alternative; boundary=Apple-Mail-122-202956174
Subject: Factoring threads & friends
To: perl6-intern...@perl.org
Message-ID: <9227ACBD-3CB1-11D8-9E96-000502994722@mac.com>
X-Mailer: Apple Mail (2.482)
X-Spam-Check-By: la.mx.develooper.com
X-Spam-Status: No, hits=-0.7 required=7.0 tests=MIME_LONG_LINE_QP,SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.44
X-SMTPD: qpsmtpd/0.26, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: malic...@mac.com (Gordon Henriksen)
Lines: 104

--Apple-Mail-122-202956174
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed

I just thought I would put forward a summary of how .NET factors its=20
thread-related data structures. It's a successful, performant, lock-free=20=

design, and I think a quite interesting factorization of what parrot=20
presently presents as "the interpreter." It's the single most successful=20=

threading design I've encountered to date.

The entities involved are the process, the thread, the "app domain."=20
These entities take separate responsibility for some of the features of=20=

the parrot interpreter.

The process is the global-most .NET state, owning threads and app=20
domains, and coordinating events such as GC. This is truly global state,=20=

and there's not a whole lot of it.

.NET threads contain little more than a stack and an instruction =
pointer.

App domains are lightweight protected execution environments. Code is=20
loaded into app domains, and types registered in data structures owned=20=

by the app domain. Objects are allocated within an app domain. The=20
majority of the .NET runtime is a property of the app domain. Individual=20=

classes and libraries cannot be unloaded in .NET, but entire app domains=20=

can be.

Stack frames are obviously within a thread's stack, and thus owned by=20
that thread. But each stack frame also is attached to a particular app=20=

domain, and thus knows how to allocate objects, etc. without the=20
overhead of an extra pointer in every object; the app domain is .NET's=20=

implicit argument, akin to parrot's interpreter parameter. If this were=20=

a relational database, one might say that a stack frame was a=20
many-to-many relationship between threads an app domains. So a thread=20
does not belong to a single app domain: This is not a hierarchical=20
design.

Objects live in one and only one app domain. Since every stack frame=20
also knows its app domain, it follows that all visible objects belong to=20=

the app domain of the executing thread. Thus memory pools can be easily=20=

identified for memory allocation, and the type registry found, etc. etc.=20=

etc.=97in general, the runtime can be utilized=97without the waste of an=20=

extra pointer in the object header.

App domains cannot directly reference each others' objects.=20
Communication between app domains most resembles RPC. Only through proxy=20=

objects can one app domain interact with another. The default behavior=20=

is that objects passed as arguments to proxy methods will be serialized=20=

and deserialized into the target app domain (although they can specify=20=

that remote proxies will instead be created in the target app domain).=20=

These proxies obviously do need to store a pointer to the peer app=20
domain, but other objects do not, keeping overhead low.

Objects do not have fine-grained locks. If their methods require=20
synchronization, their implementations must request it with a block:=20
lock (this) { /* code goes here */ }. Most of the objects in the=20
libraries are not safe for multithreaded access (although their static=20=

methods generally are).

GC affects more than one app domain: It halts all threads. (Certain=20
other events do as well, including unloading an app domain, or mucking=20=

with loaded types, or backing out JIT optimizations.) The garbage=20
collector is aware of proxy objects that bridge app domains. Since it=20
operates at the process level, it can collect garbage cycles even across=20=

app domains (where normal RPC proxies would cause reference cycles).

The .NET design doesn't meet all of requirements Dan set forth, but it's=20=

at least an interesting case study in a successful threading environment=20=

for a high-performance virtual machine.

=97

Gordon Henriksen
malic...@mac.com

--Apple-Mail-122-202956174--