[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
State management in Jace -- 50% done
- Subject: State management in Jace -- 50% done
- From: BLuRry <brendan.robert@gmail.com>
- Date: Mon, 17 Dec 2012 00:04:27 -0800 (PST)
- Complaints-to: groups-abuse@google.com
- Injection-date: Mon, 17 Dec 2012 08:04:27 +0000
- Injection-info: glegroupsg2000goo.googlegroups.com; posting-host=70.113.3.156; posting-account=HyIOQgoAAAAfAUGOevdCSBhPYcDSPtM9
- Newsgroups: comp.sys.apple2
- User-agent: G2/1.0
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.
-B