On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d wrote:
> On 18 April 2014 04:10, Kagamin via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via Digitalmars-d wrote:
>>
>>> void f(void* ptr)
>>> {
>>>   // was ptr allocated with malloc, or new?
>>>
>>
>> Then what?
>>
>
> Whatever. inc/dec ref, or not. core.memory.addRoot/Range, or not. That sort
> of thing.
>
> There's a persistent problem  when dealing with memory systems in D that it
> must remain backward compatible with C and raw pointers, and that creates
> complications.

Both NaCl and go-lang uses a trick to reserve a huge amount of continuos virtual memory...

On 18 April 2014 20:10, Tove via Digitalmars-d <digitalmars-d@puremagic.com>wrote:

> On Friday, 18 April 2014 at 00:01:25 UTC, Manu via Digitalmars-d wrote:
>
>> On 18 April 2014 04:10, Kagamin via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>  On Thursday, 17 April 2014 at 12:39:59 UTC, Manu via Digitalmars-d wrote:
>>>
>>>  void f(void* ptr)
>>>> {
>>>>   // was ptr allocated with malloc, or new?
>>>>
>>>>
>>> Then what?
>>>
>>>
>> Whatever. inc/dec ref, or not. core.memory.addRoot/Range, or not. That
>> sort
>> of thing.
>>
>> There's a persistent problem  when dealing with memory systems in D that
>> it
>> must remain backward compatible with C and raw pointers, and that creates
>> complications.
>>
>
> Both NaCl and go-lang uses a trick to reserve a huge amount of continuos virtual memory...
>

Yeah, that's what I imagined too... but does that work in 32bit apps?

On 4/16/2014 11:55 PM, Manu via Digitalmars-d wrote:
> It occurs to me that a central issue regarding the memory management debate, and
> a major limiting factor with respect to options, is the fact that, currently,
> it's impossible to tell a raw pointer apart from a gc pointer.

No it isn't, in fact, the gc has to be able to tell the difference or it cannot do mark/sweep. It tells the difference with "does the pointer point into the gc memory pool."


> What about 'hacks' like an unlikely sentinel value at ptr[-1]?

That doesn't work as soon as one increments a pointer.

On 2014-04-17 16:59, Steven Schveighoffer wrote:

> I don't think this is a viable mechanism to check pointers. It's too slow.

Couldn't a single bit be used to indicate if it's a GC pointer or not?

-- 
/Jacob Carlborg

On Saturday, 19 April 2014 at 10:30:42 UTC, Jacob Carlborg wrote:
> On 2014-04-17 16:59, Steven Schveighoffer wrote:
>
>> I don't think this is a viable mechanism to check pointers. It's too slow.
>
> Couldn't a single bit be used to indicate if it's a GC pointer or not?

I think he's hoping more for the static type system to
provide the information.  I think it would be nifty if
the fancy layered allocators that were being designed
would return pointers with types describing the allocator
itself.  Could this sort of info be useful in shared libs?