Subject: Re: CLR and Thread Safe Points

Remember that Rotor has a different GC than the CLR - their scheduling
strategies are radically different. Rotor will only poll at safe points
within JIT compiled code or from within the execution engine, and so
there is no synchronization magic that needs to happen for the benefit
of the GC (although there *is* still sync magic that needs to happen for
other reasons, such as transitions between managed and unmanaged
code...threads.cpp is a good place to go to observe the dance between
the managed thread and the PAL thread).

There is no relationship between poll calls coming from emitted code and
thread aborts (since the Rotor approach is much simpler than the
pre-emptive approach that the CLR takes). You will see calls that
remain in the code that are checking for pre-emptive GC - it was easier
to leave these in than to find all and eradicate. Sorry in advance for
that :)

With regard to thread abort in Rotor (which is an interesting exception
codepath to look at), the challenge is to "keep control" of the
execution engine while unwinding the stack for the thread being killed.
The execution engine has a number of control structures *within* the
stack (see frames.h and also the jit prolog) that need to be correctly
backed out.

I will clarify that the Rotor GC is different from the CLR GC in the
book chapter, thanks. The short description of the Rotor GC that I use
in slides is: Rotor has a polling generational collector that uses two
generations plus a separate large object heap. The younger generation
is always compacted by "promotion" (copying into the elder generation),
while the elder generation uses a mark and sweep algorithm, with first
fit allocation. There is support for interior pointer tracing that uses
a write barrier and a "remembered generation," which facilitates ECMA
managed pointers and byref semantics.

-- David Stutz


---Original Message-----
From: Bill Conroy [mailto:[email protected]]
Sent: Thursday, August 01, 2002 10:12 AM
To: [email protected]
Subject: [DOTNET-ROTOR] CLR and Thread Safe Points

I just read through the chapter 7 preview, very good BTW. I had a
question about the part on Polling the GC to say the thread is at a safe
point. I recalled reading in the .NET SDK docs[1] that aborting a thread
(Thread.Abort) will require the CLR to wait till the thread is at a safe
point to abort it.

Why is this? Because the CLR wants to be nice and not just hijack the
thread and send the exception? Because the CLR Threads don't necessarily
need to map to OS threads(although I think all CLR implementations now
do)? anything to do with the Stack, like what GC needs? ???


[1] ms-

Programming list archiving by: Enterprise Git Hosting