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

Groups > comp.lang.c > #91715

Re: A GC proposal

Show all headers | View raw

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.

>> The declarations would be in the "attributes" format. Since the
>> committee is discussing this  as an enhancement to the language let's
>> keep the (gcc) __attribute__ syntax or the microsoft __declspec syntax
>>
>> #define GC __declspec(GC)
>>
>> char * GC myPtr;
>>
>> The "GC" marked pointers would support a subset of the operations
>> possible with pointers:
>
> I'd call these GC qualified pointers.  That's the term C uses in other
> similar situations -- const qualified, restrict qualified and so on.
> Since GC often uses a technique known as 'marking' to track collection,
> avoiding the term here would help, I think.
>

Yes, we can say they are GC qualified.

>> 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.

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.

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

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.


>> 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.

> <snip>
>

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