From timurrrr@google.com on July 27, 2011 09:06:26

So how does DR handle JIT/self-modifying-code now?

From bruen...@google.com on July 27, 2011 10:49:08

it handles them correctly, but it would be more performant to have more information from the JIT.
for details of how DR handles cache consistency see
"Maintaining Consistency and Bounding Capacity of Software Code Caches",
Derek Bruening and Saman Amarasinghe, CGO 2005: http://www.burningcutlery.com/derek/docs/cacheconscap-CGO05.pdf

From timurrrr@google.com on July 27, 2011 11:02:12

Ah, OK, this is what I thought before you've mentioned this bug in https://code.google.com/p/drmemory/issues/detail?id=513 "many uninits in V8" so I've decided to double-check.

From bruen...@google.com on February 10, 2012 12:34:32

there are some details to consider here:

1. most DGC is appending to a code region and not changing code that's been
   executed. one approach is to assume that if there are annotations in
   use for a code region, then they are in use for all writes to that
   region. we would then suspend regular consistency for the region, and
   presumably the # flushes would go way down and we wouldn't pay the cost
   of selfmod instru.

   though it's not clear how we know, prior to the 1st such annotation, so
   probably have to wait for that. could add a new annotation that says
   "do not perform regular cache consistency in this memory region"

2. we would immediately shrink the vm region to something about the size of
   the region passed in the 1st annotation, to have properly-sized
   granularity of flushing

Owner: ---
Labels: Performance

From bruen...@google.com on August 20, 2014 07:42:11

Owner: byron.c....@gmail.com