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
