Re: [PREC/RFA] Add not_replay to make precord support release memory better

[Hui Zhu <teawater@gmail.com>]

On Sun, Jul 26, 2009 at 04:41, Michael Snyder<msnyder@vmware.com> wrote:
> Hui Zhu wrote:
>>
>> On Fri, Jul 24, 2009 at 10:10, Michael Snyder<msnyder@vmware.com> wrote:
>
>>> 1) During the recording "pass", there's no change.
>>> 2) During the reverse-replay pass, if the memory is
>>> not readable or writable, we will set this flag to TRUE.
>>> 3) Finally, during the forward-replay pass, if the flag
>>> has previously been set to TRUE, we will skip this entry
>>> (and set the flag to FALSE.)
>>>
>>> So my question is -- is there any reason to set it to FALSE here?
>>> Is there any way that the memory can ever become readable again?
>>>
>>> Seems to me, once it is set TRUE, we might as well just leave it TRUE.
>>> Am I right?
>>
>> I thought about it too.  I think if we don't need this entry.  We can
>> delete it directly.
>> But there is a special status, after release memory, inferior alloc
>> some memory and its address is same with the memory that released
>> memory.  Then the memory entry will can be use in this status.  User
>> can get the right value of memory before this entry.  So I think maybe
>> we can keep it.
>>
>> What do you think about it?
>
> Let's say a program does something like this:
>
> buf = mmap (...);
> munmap (...);
> buf = mmap (...);
> munmap (...);
> buf = mmap (...);
>
> and so on.  And suppose that, for whatever reason, mmap always
> returns the same address.
>
> Then it seems to me (and please correct me if I am wrong), that
> it all depends on where we stop the recording.
>
> If we stop the recording after mmap, but before munmap, then
> the memory will be readable throughout the ENTIRE recording.
>
> But if we stop the recording after munmap, but before mmap, then
> the memory will NOT be readable (again for the entire recording).
>
> So as you replay backward and forward through the recording, the
> readability state of the memory location will never change -- it
> will remain either readable, or unreadable, depending only on
> the mapped-state when the recording ended.
>
> The only way for it to change, I think, would be if we could
> resume the process and add some more execution to the end of
> the existing recording.
>

Agree with you.  We can do more thing around release memory.

But this patch make prec work OK even if inferior release some memory.
 Of course, the released memory we still can not access.  But other
memory is OK.

This is a low cost idea for release memory.  And we still can add
other thing about  release memory.


Thanks,
Hui