Re: State management in Jace -- 50% done

[BLuRry <brendan.robert@gmail.com>]

On Monday, December 17, 2012 6:22:17 PM UTC-6, Michael J. Mahon wrote:
> 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

State capture seems to be doing something.  Not sure if it is 100% correct until I hook up something to make rewinding happen.  However, I have found that I throw the JVM into periodic fits of garbage collection rage so it is important that I optimize state management at a later point to counter this.

Right now I just create objects as needed and de-reference them to let java clean up the mess.  This is normal for a Java program, but when creating disposable objects like this very often it becomes expensive to clean up all the time.  Because of this, I will need to create flyweight objects: a pool of allocated objects that are re-used rather than creating all brand-new objects.  Because this reduces the allocation/deallocation activity, it is a lot more garbage collector friendly.

I'm not going to factor this in right now: If state management is active, it might cause a game to run at 80%-90% speed from time to time.  That's just how it is until I optimize it further or unless you find the right garbage collector settings that work best on your setup.  I don't view this as a deal-breaker for the feature though.  If speed is important, don't capture states as often, or monkey with different garbage collector settings until you find one that works best.  I'll have some recommendations but don't want to get too distracted by that until I know it is at least working and stable as it is.

-B