[petsc-dev] Adding support memkind allocators in PETSc

[Barry Smith]

> On Apr 28, 2015, at 10:31 AM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>  For things like we talked about the other day. Malloc zones,
>>  .... maybe some indication that it is ok that the runtime take back
>>  this memory if available memory is running low, 
> 
> How do you communicate to the accessor that the memory has been freed?
> 
  Accessor? What is accessor?


>>  the ability to turn off read or all access to a malloc zone so that
>>  another library cannot corrupt the data, etc. When I said
>>  independent of memkind I meant having nothing to do with memkind.
> 
> Sure, and I'm not opposed to the concept, but I'd like it to somehow be
> based on information that the caller can use and have semantics that are
> implementable.  I'm also not wild about the global variables like
> PETSC_COMM_WORLD (whose use is pretty much always wrong in library
> code), so would like to know how a relevant context would be plumbed
> into the caller's scope.
> 
>>  You are correct that involves lots of nonlocal information or information that is not yet known, so the argument cannot be simple flags but must be a context that can be modified at later times.  Crude example
>> 
>>  malloc(zone1, n,&x);
>>   ....
>>  ZoneSetReadOnly(zone1);
> 
> This is implementable, just somewhat expensive.
> 
>>  ZoneSetAvailableIfNeeded(zone1);
> 
> I don't know what semantics this could have that wouldn't be a
> programming disaster.