Dave, this is excellent. Thanks. I do realize there are many diffs between the two VMs. I tend to be using Rotor a lot to 'figure out' the CLR. So, this may not be the right list for this when pinpointing behaivor in the CLR, but in my mind it's the best list.
Thanks -bc On Thu, 1 Aug 2002 11:14:47 -0700, David Stutz <[EMAIL PROTECTED]> wrote: >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? ??? > >TIA >-bc > >[1] ms- >help://MS.NETFrameworkSDK/cpguidenf/html/cpconthreadsuspendgarbagecollec >tion >safepoints.htm
