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

Groups > comp.lang.c > #91710

Re: A GC proposal

Show all headers | View raw

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.

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

> 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?  I would imagine not, but
since the overall goal of this scheme is unclear, maybe I've got that
wrong.

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

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

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