Greedy memory handling

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Sep 12 09:51:17 PDT 2013


On Thu, Sep 12, 2013 at 07:50:25PM +0400, Dmitry Olshansky wrote:
> 12-Sep-2013 17:51, H. S. Teoh пишет:
[...]
> >	struct WeakPointer(T) {
> >		enum size_t mask = 0xdeadbeef;
> >		union Impl {
> >			T* ptr;
> >			size_t uintVal;
> >		}
> >		Impl impl;
> >		void set(T* ptr) @system {
> >			impl.ptr = ptr;
> >			impl.uintVal ^= mask;
> >		}
> >		T* get() @system {
> >			Impl i = impl;
> >			i.uintVal ^= mask;
> >			return i.ptr;
> >		}
> >	}
> >
> >	WeakPointer!Buffer bufferRef;
> >
> >	void doWork(Args...) {
> >		T* buffer;
> >		if (bufferRef.get() is null) {
> >			// Buffer hasn't been allocated yet
> >			buffer = allocateNewBuffer();
> >			bufferRef.set(buffer);
> >		} else {
> >			void *p;
> >			core.memory.GC.getAttr(p);
> 
> This line above is not 100% good idea .. at least with deadbeaf as
> mask.
> 
> If we do know what OS you compile for we may just flip the say upper
> bit and get a pointer into kernel space (and surely that isn't in GC
> pool). Even then your last paragraph pretty much destroys it.

Well, that was just an example value. :) If we know which OS it is and
how it assigns VM addresses, then we can adjust the mask appropriately.

But yeah, calling GC.getAttr is unreliable since you can't tell whether
the block is what you had before, or somebody else's new data.


[...]
> Better option is to have finalizer hooked up to set some flag. Then
> _after_ restoring the pointer we consult that flag variable.

Good idea. The problem is, how to set a finalizer on a memory block that
can change in size? The OP's original situation was that the buffer can
be extended while in use, but I don't know of any D type that can
associate a dtor with a ubyte[] array (note that the GC collecting the
wrapper struct/class around the ubyte[] is not the same as collecting
the actual memory block storing the ubyte[] -- the former can happen
without the latter).


T

-- 
People tell me that I'm skeptical, but I don't believe it.


More information about the Digitalmars-d-learn mailing list