I doubt that using exceptions instead of write barriers would be faster. Handling an exception takes 10000s cycles, and it is likely only going to get worse with new CPU generations.
You could instrument the write barrier in Rotor, run some Rotor samples with it, and then calculate how fast the exception handling would have to be to beat the performance of the current write barriers. Windows have built ResetWriteWatch and GetWriteWatch APIs that allows people to use your idea without incurring the full cost of exception handling: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/ base/resetwritewatch.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/ base/getwritewatch.asp This API still has downsides like that you can only get page size granularity from it, but it is something garbage collectors could use to their advantage. BTW: The overhead of manual write barrier is less then 10 cycles if everything is in CPU cache. Compare it to the cost of cache miss: it could be more then 100 cycles. This may explain why the manual write barrier is not the performance killer of managed code. -Jan -----Original Message----- From: Alexander Petrossian [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 05, 2005 4:39 AM To: DOTNET-ROTOR@DISCUSS.DEVELOP.COM Cc: CLR Rotor Team; Jan Kotas Subject: SSCLI: write barrier quriosity [SSCLI 1.0: GC: bug(?) in brick table search [RE: SSCLI 1.0: GC: bug(?) repro case Jan, thanks a lot for your explanations! [another unrelated question goes below this small quote] I'm absolutely sure you would not mind I'd quote here these things you replied to me privately, so that people would know that salvation is near.... Jan Kotas @ Wednesday, June 29, 2005 8:27 PM [RE: SSCLI 1.0: GC: bug(?) repro case > Thanks for reporting this problem to us. It is a bug in GC. > The fix will be included in Rotor Whidbey. We have it fixed > in our internal live tree already Jan Kotas @ Thursday, June 30, 2005 7:24 PM [RE: SSCLI 1.0: GC: bug(?) in brick table search > Wow, I would never believe anybody would find this bug in Rotor! You > must have spent a lot of time going through the Rotor garbage > collector. ....current release date of Whidbey itself is second week of November, and Rotor Whidbey would be available, as I understood soon after that. ---- Jan, everybody. if you don't mind, please shed a little light on a write barrier thing: in Rotor we have fully cooperative client code. everywhere there're appropriate calls to do accounting. now how about this idea: put the burdain of checking write barrier onto VM, i.e "simply" mark pages of old generations as read-only = any attempt to write there would result in page fault, which we catch and our handler does appropriate accounting. the CORE question: is this because VM way it's still way too slow? for me it seems that writes to old generations would NOT be as often as to latest generation... while latest generation pages can be made NON write-protected -- since we do not need any accounting when user writes _there_, and this way we'd have MOST writes unchecked [while now we have them checked]. Again: I'm totally amazed that current (simple but thorough) implementation of a simple idea [manually-checked write barrier] works so quick! another reason why I ask is that I see that in CLR we have that same manual write barrier accounting (pointer "=" compiled to "call", not "mov"). thanks in advance, Alexander Petrossian, Moscow, Russia P.S. Jan, I also thought that gc_heap::find_first_object should have not been passed pointer to flagged-in-bricktable-as-big area. but there were no appropriate "assert" in code (instead, there were obscure checks), that confused me. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
