|Re: [dsdp-dd-dev] Memory service questions|
Francois Chouinard wrote:Even if I ignore multiple identical requests, I still get OutOfMemory issues when I scroll alot, so even with a CommandCache I would have problems.
Exact. Each time a memory monitor is created (by the user), the debug platform instantiates a corresponding IMemoryBlockExtension via a call to IMemoryBlockRetrieval.getExtendedMemoryBlock(). For DSF, these interfaces are implemented by DsfMemoryBlockRetrieval and DsfMemoryBlock respectively.
Following that, each time an update is requested, the UI makes a call to IMemoryBlockExtension.getBytesFromAddress(). In our case, depending on the requested block "location" (address and size) with respect to the cached block, and on the update policy (through IMemoryBlockUpdatePolicyProvider), we determine if the cached block (or parts of it) can be re-used and if a trip to the memory service is needed (IMemory.getMemory()).
If so (getMemory() was called), the retrieved block is compared with the cached block to flag the changed MemoryBytes so the UI can highlight them in the corresponding monitor.
The memory service itself should issue its requests through a CommandCache which handles the duplicates quite nicely and limits the number of trips to the back-end.
My memory service doesn't issue any debug-events at all at this time.
The issue here is that I get alot of *identical* getMemory()
requests (same address, same range, same wordsize, etc.). If I start
scrolling, the service is sometimes flooded with calls until I get a
Each of these getMemory() requests is ultimately triggered by the UI and should be factorized by the CommandCache. The UI will request a memory read upon receiving a DebugEvent (DebugEvent.CHANGE, DebugEvent.CONTENT). By any chance, does your service issue such events liberally? That could explain the flood of identical requests.
Does that mean that the memory service itself does not (and should not) set the HISTORY_KNOWN and CHANGED flags?
The HISTORY_KNOWN flag simply means that the CHANGED flag is meaningful (my english is lousy, I know...). In getBytesFromAddress(), DsfMemoryBlock compares the cached block with the newly retrieved one and flags the changed bytes. It also sets the HISTORY_KNOWN flag so the UI will correctly hightlight the changes (and put the little delta decorator too).
Not much to do then. Ideally I would like to be able to pass a primitive array (byte/short/int,long), but I don't think this will really be an issue.
As Pawel mentionned, we elected to use a MemoryByte to represent our memory blocks. And each MemoryByte comes with its personalized set of flags :-) At first glance this might look inefficient, but this is what the UI expects (see IMemoryBlockExtension).
That's not how I interpret it. If you have memory where the program has written 32-bit integers, and you tell the view to display 4-byte units, I expect the integers to come out correct. I.e. if I have this program
For the "word size", my understanding is that it corresponds to the size of the smallest addressable item, usually the byte (but, like a few other parameters, this should really be a launch configuration parameter).
uint32_t x = 0x11223344;
and display the location &x to be viewed as 4-byte units, I want the memory view to display
Endianness is not (IMHO, I should add) a property of a single byte or a byte stream, it is a way to interpret a fixed sequence of bytes read from memory. How should 4 sequential bytes read from memory be converted into a 32-bit int?
Anyway, I'll have more reason to revisit the endianness issue further down the line. It is not a critical issue at the moment.
I'll dig a little deeper into the flooding getMemory() calls and see what I can find.
Anyway, to keep things simple, I found it is easier to provide an array of bytes then let the Memory View handle the formatting (ASCII, Integer, char, ...). I suggest that you adopt a similar approach and that you provide a specific memory renderer for your more exotic rendering needs. Of course, I might very well have overseen some critical aspect and, if you have one, I would very much like to have an example where this doesn't work.
My understanding of the endianness flag (another launch configuration parameter candidate) is really for the renderer to know how to handle the raw byte array.
dsdp-dd-dev mailing list
Back to the top