| Re: [dsdp-dd-dev] Memory service questions |
Jesper Eskilson 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.Yes, apparently, but *why*? I don't see the connection between update policy and caching strategy.
Update policy determines when the view should read only from the cache and when it should invalidate the cache and read from the target.
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.
What is your host platform? Do you see similar results from clicking the scrollbar arrows? This sounds like a rendering defect.
ted