Hello,

I have a few questions & discussion points regarding core.memory.

The motivation for this post is that the current GC implementation deviates from what is promised in core.memory documentation, I'd like to correct this, but first I must confirm my interpretation of the spec / documentation is correct.

From the realloc[1] documentation:
"If p references memory not originally allocated by this garbage collector, or if it points to the interior of a memory block, no action will be taken."

It is unclear to me, whether in these cases, whether realloc should return as if an error occurred, or if to return as if it "successfully did nothing."
From my judgement, and from looking at the documentation for sizeOf[2], realloc should return as if an error occurred. Furthermore, if realloc doesn't return as if error in these cases, then it practically never returns as if error.

Returning error in these cases allows realloc to be used as a better free.
Why?
If p references memory not originally allocated by this garbage collector, or if it points to the interior of a memory block, free should do nothing. [3]
As free returns void, there is no way to know whether it actually took any action.

Free currently deviates from the documentation. As long as it is passed a pointer to GC allocated memory, regardless of whether it is an interior pointer, it will free the memory block. See the example code at the end[4].

Realloc currently has the following issues:
- If realloc is passed an interior pointer and a size parameter of zero, then realloc inherits the above issue from free, additionally, it always returns as if success.
- If realloc is passed a pointer to non-GC memory with non-zero size, it will allocate a new GC owned block when it should do nothing (and possibly return as if error.)
- Same as above except with interior pointer, this is an issue for shrinking allocations (similar to free issue,) whereas for expansion it is not a big deal (but proper behaviour should be documented specifically.)

Please discuss!

----
[1] http://dlang.org/phobos/core_memory.html#.GC.realloc
[2] http://dlang.org/phobos/core_memory.html#.GC.sizeOf
[3] http://dlang.org/phobos/core_memory.html#.GC.free
[4] Example code:
int main()
{	import core.memory;
	auto foo = cast(ubyte*)GC.malloc(4096);
	if (!foo) return 1;
	auto bar = &foo[42]; // create interior pointer
	GC.free(cast(void*)bar); // should do nothing
	GC.collect();
	GC.minimize();
	*foo = 0; // crash -> GC.free actually free'd
	return 0;
}

On 11/03/2013 03:33 AM, safety0ff wrote:
> Realloc currently has the following issues:
> - If realloc is passed an interior pointer and a size parameter of zero,
> then realloc inherits the above issue from free, additionally, it always
> returns as if success.
> - If realloc is passed a pointer to non-GC memory with non-zero size, it
> will allocate a new GC owned block when it should do nothing (and
> possibly return as if error.)
> - Same as above except with interior pointer, this is an issue for
> shrinking allocations (similar to free issue,) whereas for expansion it
> is not a big deal (but proper behaviour should be documented specifically.)
>

Most of these are sound like either implementation or documentation bugs. Please file them in bugzilla http://d.puremagic.com/issues/.
Generally we can't force implementations to provide checks that are possibly expensive to implement. So it might be more appropriate to disallow using non-GC pointer with the GC, but this needs some more thought.

On Tuesday, 5 November 2013 at 17:15:04 UTC, Martin Nowak wrote:
> Most of these are sound like either implementation or documentation bugs. Please file them in bugzilla http://d.puremagic.com/issues/.

For interior pointer issues: http://d.puremagic.com/issues/show_bug.cgi?id=11393
For non-GC pointer issue: http://d.puremagic.com/issues/show_bug.cgi?id=11446

> Generally we can't force implementations to provide checks that are possibly expensive to implement. So it might be more appropriate to disallow using non-GC pointer with the GC, but this needs some more thought.

Any preliminary thoughts on which approach should be taken for interior pointers with regards to these two functions?

On Nov 5, 2013, at 9:15 AM, Martin Nowak <code@dawg.eu> wrote:
> 
> Most of these are sound like either implementation or documentation bugs. Please file them in bugzilla http://d.puremagic.com/issues/.
> Generally we can't force implementations to provide checks that are possibly expensive to implement. So it might be more appropriate to disallow using non-GC pointer with the GC, but this needs some more thought.

Yes, please suggest implementation or documentation changes as seems appropriate.  It’s safe to assume that every GC must know whether a given pointer is into memory it owns and whether it’s an interior pointer or not, since this is required for garbage collection.  The bigger issue with non-GC pointers passed to GC operations is what the correct response should be.  Some sort of empty or soft failure response or an exception.  It’s been a while, but I think some of the requirements were established based on how memory was used inside Druntime.  There, I believe a soft fail state was important in some cases.