Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #91727

Re: A GC proposal

Show all headers | View raw

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 05/08/2016 à 10:59, Ben Bacarisse a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>
>>> We have discussed here many times the GC feature. I think this could
>>> be solved by introducing a new kind of pointers that have restricted
>>> access:
>>
>> You don't say what the problem is that is being solved by the suggestion
>> that follows.  Since GC largely works with C as it is, you should say
>> what the specific problem is.  I think, from what you write below, it's
>> all about avoiding the "false positives" of current GC schemes.
>
> Obviously. But I should have said that explicitely. It is a proposal
> to make GC not just "conservative" but 100% accurate.
>
<snip>
>>> 1: Assignment/initializations: They can be only initialized or
>>> assigned from another pointer also marked as "GC".
>>
>> Are casts permitted?  Given a void *vp, the expression (char *GC)vp is a
>> GC qualified pointer.  Could that be used?
>
> Of course, we are in C. You can do today:
>
> char *p = (char *)0xdeadbeef;
>
> *p = '?';
>
> and your propgram will crash. And it is your fault.

That's missing the point!  Is it *valid* to take a pointer and cast it
to be being GC qualified?

>> I would imagine not, but
>> since the overall goal of this scheme is unclear, maybe I've got that
>> wrong.
>
> The main goal is to make an accurate description of memory to be used
> with the GC.

So, no.  You can't add GC qualification with a cast (nor cast it away?)
and still have a correct program.  Is that about right?

>>> 2: Once initialized they can't be changed (they are all implicit
>>> "const").
>>
>> Do you really mean initialised or do you mean "first assigned"?

It would really help if you answered this.

>> If you mean initialised (in the C sense), then there will be lots of
>> important cases where you can't use GC qualified pointers.  I'm
>> thinking of classic GC use cases such as dynamic lists and trees.
>>
>
> 1: If you allocate the nodes of the list using the GC it will work
> without any problems.
>
> typedef struct tagNode { char * GC next; int data; } Node;
>
> In this cases all nodes are allocated with the GC attribute. You can
> then have all Node pointers garbage collected.

I can't square that with the other things you've said.  You say that GC
qualified pointers can't be assigned (they are implicitly const) so how
does the 'next' pointer get a new value?

And if the allocator must know the types, you can't have any GC
qualified pointers in malloc'd storage.  That's fine, but I think you
need to say it.

> Note that a normal pointer can receive the value of a GC allocated
> pointer to go through the list or to keep a pointer to the last node
> or whatever.

Ah, this sounds dangerous.  If I go through the list with a non-GC
pointer there may be times when that is the only pointer to a node
(during unlinking of a node for example).  Now you can say that the
programmer just made a mistake but surely you want to make memory
management less prone to hard to find bugs.  I would ban casting away GC
qualification.

>>> 3: They can't be stored in unions.
>>>
>>> 4: If not initialized at the start of the function, non-initialized gc
>>> pointers would be automatically initialized to NULL at the function
>>> entry.
>>>
>>> The compiler can then provide an environment where the GC can be VERY
>>> accurate, not jkust conservative, as it is now. The compiler would
>>> emit a set of tables containing for each scope the addresses of all
>>> pointer marked as GC. The GC algorithm would be then like this:
>>>
>>> 1) From the current frame, mark as used all pointers in the current
>>> function.
>>>
>>> 2) Use the stack unwind info to retrieve the calling function, mark
>>> those until the global scope is reached and mark all that one too.
>>>
>>> 3) Do this for each thread.
>>>
>>> 4) Unmarked memory is free.
>>
>> This seems to rule out having GC qualified pointers in allocated
>> storage.  That's going to seriously reduce its usefulness.
>>
>
> Suppose:
>
> struct S { int a; char *GC; };
>
> int foo() {
>    struct S s;
>
> // ...
> }
>
> The compiler can then emit the offset of the pointer in the structure
> and allow the GC to follow the pointers in the allocated data.

There is no allocated storage (in the C sense) here.  I was talking
about malloc and friends.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A GC proposal jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:34 +0200
  Re: A GC proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 09:59 +0100
    Re: A GC proposal jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 11:29 +0200
      Re: A GC proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:48 +0100
  Re: A GC proposal luser droog <luser.droog@gmail.com> - 2016-08-05 12:18 -0700
    Re: A GC proposal supercat@casperkitty.com - 2016-08-05 12:32 -0700
      Re: A GC proposal jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 22:07 +0200
        Re: A GC proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 21:50 +0100
          Re: A GC proposal supercat@casperkitty.com - 2016-08-05 14:32 -0700
          Re: A GC proposal jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 00:05 +0200
            Re: A GC proposal Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:28 +0200
            Re: A GC proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 01:47 +0100

csiph-web