[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: State management in Jace -- 50% done



BLuRry <brendan.robert@gmail.com> wrote:
> There is currently nothing to show unless you browse the source tree, but
> the state management support in Jace is at 50% completed.  I have it
> hooked in to the rest of the emulator and have made it configurable so
> that you can control how many states to track and how often states are
> captured (as a ratio of VBL intervals, so if you specify 1 it will
> capture a state on every VBL.  2 will capture every other VBL and so on.)
> 
> I have written all the semantics that define capturing the full emulator
> "alpha" state as well as tracking changes to the emulator in more compact
> "delta" states.  This should avoid redundant and expensive memory copies.
> 
> The state manager will not go beyond 90% heap capacity.  If the user
> tells the state manager to capture a billion states, it will effectively
> capture only as many as it can fit in memory without exceeding 90% heap
> usage.  In reality this is rarely ever going to be a big issue.
> 
> I need to implement some specific behavior to handle the screen (because
> the screen contents have a special visual meaning for the state manager)
> and also paged memory, because paged memory will be tracked by changes
> per page and not treated as one big object.
> 
> After all is said and done, I will then come up with some sort of
> testing/debugging UI for this feature and then eventually make that into the rewind UI.
> 
> It's coming along.  Maybe not quite as easily as I'd hoped, but I'm not
> blocked by anything other than available free time.

Just being able to run time backward is a very powerful debugging tool. 

If you allow a restore to a captured state, then step forward N
instructions, then re-restore and step forward N-1 instructions, etc., the
effect is that of backing the program up one instruction at a time. 

Many powerful tools can be constructed from this kind of "reverse
execution", with breakpoints, memory access traps, etc., all done "after
the fact". 

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon