www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.memory GC interface / specification

reply "safety0ff" <safety0ff.dev gmail.com> writes:
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!

----



[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;
}
Nov 02 2013
parent reply Martin Nowak <code dawg.eu> writes:
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.
Nov 05 2013
next sibling parent "safety0ff" <safety0ff.dev gmail.com> writes:
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?
Nov 05 2013
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Nov 5, 2013, at 9:15 AM, Martin Nowak <code dawg.eu> wrote:

=20
 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=92s safe to assume that every GC must know whether a =
given pointer is into memory it owns and whether it=92s 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=92s 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.=
Nov 05 2013