On Wed, Oct 22, 2008 at 3:06 AM, Jesper Eskilson
<jesper.eskilson@xxxxxx> wrote:
Pawel Piech wrote:
No this is actually intentional. The cache in the memory block is used to implement the manual update policy where the memory view is updated only per request.
There are 3 update policy options:
[1] Automatic i.e. refresh the monitor(s) on demand (from the UI)
[2] On breakpoint i.e. refresh the monitor(s) only when a breakpoint is hit
[3] Manual i.e. refresh the monitor(s) only at the user request (button)
[1] is the regular case meaning that if the UI cares to ask for a memory update, it will be provided with one. Caching then happens in the Memory service to avoid sending repeatedly the same request to the back end.
[2] and [3] are used to ease the load on the Memory service. If you select either, the cached memory block will be returned - if possible - even if it is stale.
Maybe the default policy ([1]) is not appropriate and should be changed to [2]. BTW, wouldn't it have been easier to just change the update policy from the context menu rather than modify the DsfMemoryBlock code?
BTW, can you elaborate more on what memory rendering you're using? When I put a trace in the Memory.getMemory(), I only see it being called once with the Hex rendering, and on the order of 10 or 100 times with the Traditional rendering. I never see it called 1000s of times.
I'm using the traditional rendering. I'll try some of the others to see what happens. When dragging the scrollbar (with the traditional renderer), it sometimes peaks at upward 5000 identical requests.
I changed DsfMemoryBlock so that it caches even for automatic update policies, but this only transfers the problem from the memory service to the DsfMemoryBlock class; getBytesFromAddress() is flooded by calls from the memory renderer. I could not reproduce the OutOfMemory crash, but just dragging the scrollbar up and down a little causes the Eclipse process to consume ~180% CPU for several minutes.
Then it would seem that the cause of requests flood might be in the memory renderer. Rather than patching DsfMemoryBlock maybe we should have a closer look at this one.
--
/Jesper
