> >This message does remind me of how empty the TODO list is. Surely we > >can think of many more things to be done? > > Speaking of.. > > 1) Bugfix release please, we banged quite a few stack and GC bugs out. > Don't we get any dessert?
Peter has already stated he'd like his parrot_reallocate_buffer patch to go in first, as it does fix a reproducible bug with clint's evaluator. And there's still a bunch of GC bugs. I know of three types: 1) The problem that's been brought up before (and below), of CPU-stack vars not being traceable. 2) The GC initialization stuff could potentially trigger a GC (woops!). My fix was to disable the GC during interpreter initialization, but I'm not sure what we want to do for this. 3) Non-string buffers (ie, stuff in last_Buffer_Arena, not last_String_arena) are pretty broken, I think. They aren't marked, unmarked, freed, or copied. I could be mistaken on this one, as I don't have any test cases that break it yet, just my understanding of the code. This should be a lot easier to fix, with a little copy and paste. But I'd like to get a valid test case before I attempt to fix this. > 2) I'm thinking of an internal stack not visible to user code that we use > for temporary PMCs and Buffers and a simple macro for entry and > exit of GC sensitive routines. I think I might have mentioned this. What defines a GC-sensitive routine? Anything that does string manip, pmc manip, or any allocations, is marked GC-sensitive? > I'd like something like this rather than hoping all developers can > systematically set bits or handle references correctly because in > reality we'd probably never catch all the cases. Two things: First, we now have a GC_DEBUG define that we can turn on to find all places the GC could cause problems. In the current state, I think it covers 90% of the problems (one problem is that if I conditionally call string_make, this function isn't guaranteed of triggering GC in a test case, like it should.) However, if we can't find all the places we do buffer manipulation to mark them immortal, how are we going to properly identify all the GC-sensitive functions? Secondly, setting a flag should be much quicker, speed-wise. We'd only be setting flags on buffer headers that are already in the CPU cache, as opposed to writing to memory in this stack, pushing and popping all the time. And if we macro-ize the setting of the flags, I don't think it should look nearly as bad. GC_MARK(Buffer), GC_UNMARK(Buffer), etc. I know there's been little activity in the past week...as far as my activity, I'm waiting for the Dan to come back tomorrow, and tell us minions what the plan is for GC stuff. Peter and I fixed most of the GC bugs that are easily fixed, but the rest require a more architectural fix, something I think we all are deferring to Dan on. Mike Lambert
