[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