Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: A GC proposal |
| Date | 2016-08-06 00:05 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <no32ij$hb9$1@dont-email.me> (permalink) |
| References | <no1j21$aja$1@dont-email.me> <1036d97e-fad2-48b8-ba6f-b46d77eb4e1f@googlegroups.com> <02e12ece-7664-4bb9-bf0b-7c9a4271a4f6@googlegroups.com> <no2rli$mjn$1@dont-email.me> <877fbvos8q.fsf@bsb.me.uk> |
Le 05/08/2016 à 22:50, Ben Bacarisse a écrit : > how do you determine what pointers need to be followed? Obviously the > content of u, but then what? This is equivalent to figuring out embedded pointers in a data structure. The compiler leaves to the gc information about which pointers are at which offsets in the types of us1s2. The first points to an s1 structure that has a pointer to be followed at offset zero. The second points to a structure s2 with pointers to be followed at offset 8 and 16. Since the types of those are known, the gc marks them and goes on following each of them in sequence. Thanks for conributing to this thread Mr Becarisse. As you see I am trying to figure out what would need to be generated for a GC in C, but not a probabilistic one but one powered by information the compiler leaves to it. That eliminates false positives. It leaves the question of infinite loops in circular structures. Then, this GC would MUCH faster and simpler than the one of Mr Boehm's. That is an impressive piece of software of course, but it has a brute force algorithm. This one is much faster since it doesn't chase pointers blindly in all space but knows where are the real pointers! Besides, obvious speed ups can be detected at compile time: At function exit any GC pointer that is local to that function and has not been passed to any function can be safely freed immediately.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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