Strange C developments

[John Bode]

Hi Can anyone explain why C has added support for pthreads, while NOT
adding support for garbage collection? Convenient memory management would
be a much greater enhancement than replicating a perfectly good existing
library it seems to me.

Jase

The main objection to automatic garbage collection in general that I've seen is its non-determinism, which can play hell in a realtime system. The general response to *that* is "when's the last time you had to work on a hardrealtime system, Jack?" (for me, the answer is "never").

Could be there was simply more demand from the C programming community for language-supported threading than for AGC.

Could also be that WG14 felt that the changes necessitated by threading were enough for one revision, or that the changes necessitated by GC would negatively impact legacy code or be too hard to implement with the current C architecture. I know that for myself, the behavior of malloc/realloc/calloc/free had damned well better not change *at all*; if you're going to add AGC, create a new library or add new functions to stdlib.

I haven't seen a C 2011 Rationale; would be nice to know what WG14 was thinking for this revision.

Seebs?

 

[Philip Lantz]

You keep on saying this. What does it mean?

To me, it means, "I don't really know what I'm talking about; you should
just ignore all the foregoing. In fact, to save time in the future, you
should probably just kill-file me."

I'm pretty sure that's not what BGB wants me to think, so I wish he
would stop saying it. I do still read his posts.

 

[Philip Lantz]

Do I have to set the pointer to NULL if it's stored in an auto
variable (not in main()) and the ptr = NULL; statement would be
immediately followed by a return statement?

Most likely in that case the compiler would know the variable is dead
and not actually store the NULL, so it wouldn't help the GC anyway
(unless there was some knowledge of the GC built into the compiler, but
I think the topic under discussion is the case where it isn't).

Any time registers containing pointers are saved in the stack, such as
before calling another function or in a function prologue, the GC has to
treat those pointers as live. Then when that stack area is reused for a
different stack frame, it is often not fully initialized, and the GC
will still see those pointers as live, even when they are just leftover
junk on the stack.

Whether or not this significantly limits the GC depends on the way the
code uses pointers.

 

[Nick Keighley]

Le 21/07/12 12:23, Quentin Pope a écrit :








To port existing code to a GC environment you do not need to change a
single line. Just define malloc as gc_malloc and define free as a noop.


??? That is not the case with the GC used by lcc-win.


Yes, that kind of code shouldn't be used with a GC.


The gain is that instead of loosing endless hours tracking that dangling
pointer in the debugger you can concentrate on your application instead.


You fail to mention "With careful programming and not making any
mistake. NEVER. A single moment of inattention and you are screwed.

Leave it for the kiddies programming


JAVA, Lisp, C++, C, all the languages that can be used ith a collector.

JAVA and Lisp have to have GC. C++ and C may have a limited GC

 

[Nick Keighley]

2) In modern machines a collector slows down the program for at most
a milisecond in normal situations, that could be bigger but not much
bigger since the collector tries to spread out the GC time in each
allocation.

whilst that's impressive even a milisecond might matter in some real
time systems

 

[Nick Keighley]

[various allocations stratagies listed]

"and so on" "or in a similar fashion"

To me, it means, "I don't really know what I'm talking about; you should
just ignore all the foregoing. In fact, to save time in the future, you
should probably just kill-file me."

I'm pretty sure that's not what BGB wants me to think, so I wish he
would stop saying it. I do still read his posts.

I thought his point was that different sorts of memory may need
different allocation strategies was pretty uncontroversial. Not sure
why it deserved the snotty response...

 

[Nick Keighley]

the conter-point is simply this: programmer has to think
on memory of his/her program...


you can not compare what you control of what you not controll
at all...
if someone want to be a programer, he/she has to build his/her own
malloc routines only for to have more
controll hisself/herself program memory...
so the way is opposite of use gc() etc...

nonsense

 

[Malcolm McLean]

בת×ריך ×™×•× ×©×œ×™×©×™, 24 ביולי 2012 09:23:03 UTC+1, מ×ת Nick Keighley:

On Jul 21, 6:03 pm, jacob navia '(e-mail address removed)' wrote:

whilst that's impressive even a milisecond might matter in some real
time systems

You've got twenty of them per frame in a 50 frames per second video system.So the garbage collector itself won't take down the system. However it's not a negligible consumer of resources.

 

[BGB]

whilst that's impressive even a milisecond might matter in some real
time systems

hard real-time, maybe.
then the usual strategy would be not to use a GC.
in any case, it would be best if C preserved the right to choice as to
whether or not GC is used.


soft real-time is, well, softer. typically, the matter of whether or not
a GC is used can be more left to the impact it may have on the user
experience. assuming that the GC is not running all the time (this is
likely only really in pathological conditions), the negative impact is
fairly small, but may allow delivering a better user experience overall
(while at the same time, preventing slower memory leaks from eventually
crashing the program).

speed critical code may also refrain from allocating memory or using
dynamic type-checking as well.


actually, as-is, GC libraries supply a choice as to whether or not GC is
used, apart from people arguing that "there is no choice, since they are
unusable".

any sort of standard GC would likely still need to preserve choice, and
hopefully not be too far in "lame duck" territory either.



decided to leave out anecdotes related to my experience plugging my GC
into the Quake 2 "hunk"-allocator system (basically, memory allocation
in a manner similar to a large stack).

 

[Stefan Ram]

C might well be faster - once you've finally finished and debugged the
application.
Meanwhile your competitor has had his application out for six months,
because he's used a different approach. And he can upgrade his product more
quickly.

And how do you explain the reports on TIOBE and other sites
according to which C has knocked GC-Java from its top position?

 

[Nick Keighley]

You've got twenty of them per frame in a 50 frames per second video system. So the garbage collector itself won't take down the system. However it'snot a negligible consumer of resources.

I didn't say "video" did I?

 

[Nick Keighley]

"Nick Keighley" <[email protected]> ha scritto nel messaggio

"Tim Rentsch" <[email protected]> ha scritto nel
messaggionews:[email protected]...

the conter-point is simply this: programmer has to think
on memory of his/her program...

you can not compare what you control of what you not controll
at all...
if someone want to be a programer, he/she has to build his/her own
malloc routines only for to have more
controll hisself/herself program memory...
so the way is opposite of use gc() etc...

nonsense

#the nonsense is almost all [but 2 people not] that write here
#have fear in think or managiament memory they programs use

incomprehensible.

if I guess right you suggest I'm scared to write my own version of
malloc.
I simply don't see the point. I've written fixed block allocators.
Since
malloc() is suppiled with my C library I've had no compulsion to write
my own.
Life's too short.

 

[BartC]

#the nonsense is almost all [but 2 people not] that write here
#have fear in think or managiament memory they programs use

incomprehensible.

if I guess right you suggest I'm scared to write my own version of
malloc.
I simply don't see the point.

One of the benchmarks[1] I was using on my compiler project was,
miraculously, faster than gcc, no matter what the latter's optimisation
level.

Ie. always 4.2 seconds, compared with gcc's 5.6 seconds. Then I discovered
the timing of this benchmark is mostly based around calls to malloc() and
free(). Two other C compilers were both around 2.4 seconds. I was using
lcc-win's library.

I plugged in my own allocator, built on top of malloc(), which was better at
lots of small allocations, and my timing was then 1.2 seconds!

So, you were saying about there not being any point? (Of course this was not
rewriting malloc(), but the large memory blocks I worked with could just as
easily have come from the OS, and given had the same results.)

(Sadly I had to retire this benchmark, as it was not actually testing
generated code.)

[1]
http://shootout.alioth.debian.org/u32/program.php?test=binarytrees&lang=gcc&id=1

 

[tom st denis]

Interestingly, Apple just killed garbage collection in their Objective-
C compilers and never moved support for GC to the iPhone.
So someone there thinks that garbage collection isn't _that_ useful.
And sorry to say, but C wasn't designed with garbage collection in
mind.

Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically.

That sort of syntax would make certain functions a bit easier to work
with, infinitely more useful would be something like

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.

 

[88888 Dihedral]

BGBæ–¼ 2012å¹´7月24日星期二UTC+8下åˆ10時55分33秒寫é“：

hard real-time, maybe.

then the usual strategy would be not to use a GC.

in any case, it would be best if C preserved the right to choice as to

whether or not GC is used.





soft real-time is, well, softer. typically, the matter of whether or not

a GC is used can be more left to the impact it may have on the user

experience. assuming that the GC is not running all the time (this is

likely only really in pathological conditions), the negative impact is

fairly small, but may allow delivering a better user experience overall

(while at the same time, preventing slower memory leaks from eventually

crashing the program).



speed critical code may also refrain from allocating memory or using

dynamic type-checking as well.





actually, as-is, GC libraries supply a choice as to whether or not GC is

used, apart from people arguing that "there is no choice, since they are

unusable".



any sort of standard GC would likely still need to preserve choice, and

hopefully not be too far in "lame duck" territory either.







decided to leave out anecdotes related to my experience plugging my GC

into the Quake 2 "hunk"-allocator system (basically, memory allocation

in a manner similar to a large stack).

The GC part can be implememted by reference counts.
But that adds overheads to using every objet.

There is another way to achieve the same funtionalities as the GC.

But that will involve error trapping and serializing objects to be storable to the hard disk, and perform jobs in a shell way that can be safely exited in all modules.

It is as difficult as building the OS mmu part.

 

[Jens Gustedt]

Am 02.08.2012 15:08, schrieb tom st denis:

Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically.

That sort of syntax would make certain functions a bit easier to work
with, infinitely more useful would be something like

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.

Why would you need such a "heap" marker syntactically?

For your first example for the pointer (syntactically) I would just do

int foo[1];

An implementation could just decide to allocate "auto" arrays on the
heap, and free everything at the end of the liftime of the variable. You
don't have to add a jota to the syntax of C for that.

The downside of such a "heap" approach for array allocation is that the
implementation of setjmp/longjmp would be come a bit more complicated.
You can't just re-adjust the stack pointer but you'd have to re-invent a
mechanism that "free"s all the allocated arrays on the way down, once
you jump to a different function stack. Isn't completely trivial.

Jens


* Unbekannt - erkannt
* Englisch
* Deutsch

* Englisch
* Deutsch

<javascript:void(0);> <#>

 

[gwowen]

Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically... infinitely more useful would be somethinglike

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.

Replace "signal" with exception, and you've just (re-)invented the key
point of of C++ RAII? Personally, I find resource management with
RAII far more convenient than GC -- though I appreciate that GC has
some advantages -- as it works for more than memory.

In fact, RAII is the single biggest thing that makes C++'s esoteric
horrors worth putting up with.

 

[tom st denis]

Am 02.08.2012 15:08, schrieb tom st denis:

Syntactically it'd be pretty easy to have something like

heap int *p;

where "heap" defaults to init it to NULL and then at the end a call to
free() is made automatically.

That sort of syntax would make certain functions a bit easier to work
with, infinitely more useful would be something like

heap int foo[34]; // or whatever array size

Where it allocates "foo" off the heap (via calloc) automagically,
raising a signal if it fails, and then when the function returns it
calls free() on it.

That would be very useful for small stackframe applications.

Why would you need such a "heap" marker syntactically?

For your first example for the pointer (syntactically) I would just do

int foo[1];

An implementation could just decide to allocate "auto" arrays on the
heap, and free everything at the end of the liftime of the variable. You
don't have to add a jota to the syntax of C for that.

The downside of such a "heap" approach for array allocation is that the
implementation of setjmp/longjmp would be come a bit more complicated.
You can't just re-adjust the stack pointer but you'd have to re-invent a
mechanism that "free"s all the allocated arrays on the way down, once
you jump to a different function stack. Isn't completely trivial.

Are there real people who use setjmp()/etc in everyday code? I've
never once used them despite all the oddball places my code has been
found.

And while the compiler could automagically decide to take from the
heap for auto variables it would be nice for that to be more manual.

Tom

 

[Noob]

Are there real people who use setjmp()/etc in everyday code? I've
never once used them despite all the oddball places my code has been
found.

IJG's libjpeg uses longjmp to bail out on error
(I suppose the author didn't want to propagate errors.)
Kinda hairy, in my opinion.

 

[Anders Wegge Keller]

Are there real people who use setjmp()/etc in everyday code? I've
never once used them despite all the oddball places my code has been
found.

if (timeout) {
signal (SIGALRM, alarm_int);
alarm (timeout) ;
}
if (setjmp (timrenv) == 0) {
retval = routine (param1, param2) ;
/* this is a normal return */
} else {
/* we come here after a timeout */

Our codebase have several places where timeouts are handled by
setjmp/longjmp as the snippet above. The alarm handler finish with a
longjmp(). This is legacy code, originally deployed on Xenix. I've
been lead to beleive that this was the only reliable way of handling
socket timeouts on that platform.