<div dir="ltr">I think this is maybe getting away from the heart of the discussion, but anyway: Barry, you are talking about being able to mark certain allocated regions as "optional" and then have those allocations disappear, right?  I could see, say, having such an "optional" allocation that is backed by a file on some sort of "fast" storage (some super-fancy SSD or NVRAM) and whose pages can be evicted if the memory is needed.  I don't know that I like a pointer to that just being nullified if the eviction occurs, though.  For a case like this, I'd like to do something like have a Vec and only have this happen to the array of values if no "get" is outstanding.  This puts us back with an array to the numerical values that could get swapped around.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 8:44 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
>   The special malloc would need to save the locations at which it set<br>
>   the addresses and then switch the address to NULL. Then the code<br>
>   that used those locations would have to know that they that they may<br>
>   be set to NULL and hence check them before use.<br>
<br>
</span>And then PetscMalloc(...,&tmp); foo->data = tmp; creates SEGV at some<br>
unpredictable time.  Awesome!<br>
<span class=""><br>
>   I am not saying this particular thing would be practical or not,<br>
>   just that if we had a concept of a malloc context for each malloc<br>
>   there are many games we could try that we couldn't try otherwise and<br>
>   this is just one of them.<br>
<br>
</span>I'm not convinced, except in the case of mixing in madvise hints.<br>
</blockquote></div><br></div></div>