|
From: Oleksandr K. <ti...@gm...> - 2006-07-07 10:45:07
|
Julian Seward <jseward <at> acm.org> writes: > > > All, > > As a result of recent memcheck hackery in the 3.0 line, I broke > support for the VALGRIND_SET_VBITS and VALGRIND_GET_VBITS > client requests. I haven't fixed them; instead I am hoping to > get rid of them altogether. They were introduced as an experimental > hack, and as far as I know nobody ever used them. > > So my question is: does anybody use these? > > If you haven't a clue what this is about, it's a pretty safe bet > you don't use them. > Hi, I do need the GET/SET VBITS requests! The case is when one implements virtual memory-like system in which memory contents may be offloaded from RAM even if memory page's contents is only partially defined (and the page is dirty already). It is actually for "memory buffer" of a database management system (for non- standard embedded environment). All data is processed in one region of memory where memory pages loaded and offloaded from/to disk. The pattern to use is: GET_VBITS(...); // save vbits state MAKE_READABLE(page, page_size); // prevent complaints when page data is writen to file MemoryBuffer::SavePage(page, ..); // save(flush) page - it stays in memory SET_VBITS(...); // restore It becomes even worse, if there is a need to preserve VBITS for completely offloaded pages. Then, in debug builds VBITS must be stored along with memory pages' data in file system and restored when page is brought back into the memory buffer! - Oleksandr |