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

Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection?

GC in 'C' is a non sequitur.

> Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>
> Jase
>

I think you want Java, then.

--
Les Cargill

On Jul 20, 10:14=A0pm, Jase Schick <nos...@nospam.com> wrote:
> 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.

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.

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:
>And sorry to say, but C wasn't designed with garbage collection in
>mind.

  I believe that a GC is both important and nice, a great productivity
  enhancer, but for /higher-level languages/. C, on the other hand,
  is /intended to be/ a low-level language. A language that adds just
  a thin layer over the machine language. It is intended to be
  a language to possibly /implement a garbage collector in/, when 
  it should be needed for a higher level language.

  This is about layering: One does not complain that features of a
  higher layer are not present in a lower layer, because this would
  break the layering. When one wants to use Perl, Java, or LISP 
  instead of C, one is always free to do so.

  There also is the Boehm-Demers-Weiser conservative garbage collector.

Jase Schick wrote:

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

Why do you believe that garbage collection should be added to the C 
standard?


Rui Maciel

On 7/20/2012 4:14 PM, Jase Schick wrote:
> 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.
>

more people can agree on the behavior of a threading library than they 
can on the behavior of a GC library?...

a few possible issues with a GC:
precise or conservative GC?
how does it represent references?
how does it interact with stack variables, global variables, or malloc?
does it simply behave like malloc, or does it also preserve type 
information?
....

some of these issues would need to be addressed, and as-is, people get 
by ok either using or implementing garbage-collection via libraries.

On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:

> Hi Can anyone explain why C has added support for pthreads, while NOT 
> adding support for garbage collection?

GC requires a "walled garden", which C isn't.

You can't just "add support" for GC, you have to design the language
around the ability to enumerate references.

Le 20/07/12 23:14, Jase Schick a écrit :
> 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 lcc-win compiler offers a garbage collector (Boehm's) in its 
standard distribution. It is a very useful feature, used for instance in 
the debugger of lcc-win, in the IDE and several other applications. Of 
course it is used by many of the people that have downloaded lcc-win 
(more than 1 million)

On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
> Le 20/07/12 23:14, Jase Schick a écrit :
>> 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 lcc-win compiler offers a garbage collector (Boehm's) in its
> standard distribution. It is a very useful feature, used for instance in
> the debugger of lcc-win, in the IDE and several other applications. Of
> course it is used by many of the people that have downloaded lcc-win
> (more than 1 million)

Do you never get tired of spamming this group with advertising for your 
compiler?

Adding garbage collection would break a large amount of existing code.

Often the bottom couple of bits of pointers to memory with known 
alignment properties will be used to store information (the pointer than 
being and'd with ~0x3ul or similar prior to dereferencing).

Many code protection methods rely on storing pointers xor'd with an 
obfuscating mask. GCs are not sophisticated enough to track such pointers.

And what is the gain? With careful programming, there is no need 
whatsoever for this stupid overhead. Leave it for the kiddies programming 
JAVA.

//QP

Le 21/07/12 12:23, Quentin Pope a écrit :
> On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
>> Le 20/07/12 23:14, Jase Schick a écrit :
>>> 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 lcc-win compiler offers a garbage collector (Boehm's) in its
>> standard distribution. It is a very useful feature, used for instance in
>> the debugger of lcc-win, in the IDE and several other applications. Of
>> course it is used by many of the people that have downloaded lcc-win
>> (more than 1 million)
>
> Do you never get tired of spamming this group with advertising for your
> compiler?
>
> Adding garbage collection would break a large amount of existing code.
>

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.


> Often the bottom couple of bits of pointers to memory with known
> alignment properties will be used to store information (the pointer than
> being and'd with ~0x3ul or similar prior to dereferencing).
>

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

> Many code protection methods rely on storing pointers xor'd with an
> obfuscating mask. GCs are not sophisticated enough to track such pointers.
>

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

> And what is the gain?

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


> With careful programming, there is no need
> whatsoever for this stupid overhead.

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

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

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=91=D7=AA,=
 21 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 11:23:52 UTC+1, =D7=9E=D7=90=D7=AA =
Quentin Pope:
>=20
>=20
> Often the bottom couple of bits of pointers to memory with known=20
> alignment properties will be used to store information (the pointer than=
=20
> being anded with ~0x3ul or similar prior to dereferencing).
>=20
> Many code protection methods rely on storing pointers xored with an=20
> obfuscating mask. GCs are not sophisticated enough to track such pointers=
..
>=20
Rarely do you need to do this sort of thing, particularly in a hosted envir=
onment.

The gain is that far too much C code is concerned with handling memory allo=
cation failures and clean-up that can't happen. For instance user provides =
a list of filenames in a configuration file. I need to read them in and ret=
urn as a list of strings. If a memory allocation failure occurs halfway thr=
ough building the list, I've got to deallocate a half-built list, and retur=
n an error condition, probably a null pointer. The code to handle this will=
 probably be about half the function, even though if I've 4GB of memory ins=
talled, and the total allocation is 1000 bytes, the computer is more likely=
 to suffer an electrical failure than it is to run out of memory.

Thne you've got to write  little function just to deallocate the list of st=
rings, in normal use.

The reason I don't use garbage collection is a) it's non-standard and b) mo=
st garbage collectors are unacceptably inefficient for high performance rou=
tines. But it's a blessing from the coding angle.

>> Adding garbage collection would break a large amount of existing code.
>>
> 
> 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.

Jacob, what rules would have to be added for application writers
to use the GC in lcc-win besides the C standard and "don't invoke
undefined behavior"?  Hint:  the answer is not "none".  And that's
not intended as a put-down of lcc's GC or GC in general.

Or, to put it another way which I'm sure you will still think of
as a personal attack, list the things an application programmer
could do to break GC that no sane programmer would do (someone will
come up with a sane-sounding reason for doing it anyway) but the C
standard still allows.  If the C standard calls it undefined behavior
on the part of the application, GC is off the hook.

I'll define "break GC" as any one or more of the following:
- Collecting non-garbage
- Aborting the program with things like segfaults.
- A 1,000,000% slowdown
- A GC so conservative it never collects anything.


I'm pretty sure that writing pointers to a (potentially terabyte)
temporary file, erasing the pointers from memory, and later reading
the pointers back from the file (all done by the same run of the
same program) will either confuse or horribly slow down GC.  And I
think that's perfectly OK with the C standard.  

>> Often the bottom couple of bits of pointers to memory with known
>> alignment properties will be used to store information (the pointer than
>> being and'd with ~0x3ul or similar prior to dereferencing).
>>
> 
> ??? That is not the case with the GC used by lcc-win.

I take that to mean:  often an application program will abuse the bottom
couple of bits of pointers to memory with known alignment properties to
store information, and this will break the GC.  I think doing that to
pointers invokes undefined behavior, at least if you do stuff like
	void *ptr;

	ptr |= 3;
or 	ptr &= ~3;

so the GC has a perfectly good excuse for breaking.

>> Many code protection methods rely on storing pointers xor'd with an
>> obfuscating mask. GCs are not sophisticated enough to track such pointers.

Code protection methods are designed to break the application, but
the C standard doesn't forbid that.

I'm not sure the C standard allows that specific method of disguising
pointers, but I think you are allowed to format a pointer with
sprintf() and %p, erase the original pointer, then later feed the
buffer sprintf() wrote into sscanf() and %p, and get back the same
pointer.  While it's in text form, you could do all sorts of things
to it (encrypt, store it in a file, etc.) , as long as it eventually
gets back to the original text.

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

People want to know how to recognize "that kind of code" and not
try to use GC with it, rather than trying it and figuring it out
the hard way.  And I don't really see a "don't disguise pointers"
rule as being too onerous if you can clearly define what *ISN'T*
disguised.  Probably 99.9% of programs would need no change.

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

Oh, yes, another rule for a working GC is that the GC has to
occasionally actually collect some garbage if there's any around
to collect.  It doesn't have to catch everything immediately, but
code like:

#define malloc(x) gc_malloc(x)
int main(void)
{
	while(malloc(6)) { /* loop */ }
}
shouldn't terminate the loop because malloc() eventually returns NULL
due to insufficient collection of garbage.

On 7/21/2012 4:32 AM, Nobody wrote:
> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>
>> Hi Can anyone explain why C has added support for pthreads, while NOT
>> adding support for garbage collection?
>
> GC requires a "walled garden", which C isn't.
>
> You can't just "add support" for GC, you have to design the language
> around the ability to enumerate references.
>

actually, it can be done, but mostly in the form of conservative GCs, 
such as Boehm.

I also use a GC, which is functionally similar to the Boehm GC as well, 
but differs mostly in the use of type-tagging (and some ability to 
assign special treatment to type-tags), so it is a little different.

I ended up primarily using it with a hybrid strategy, where manual 
memory-management is used for the most part, and GC is used mostly to 
clean up for the case of memory leaks.

On 7/21/2012 8:57 AM, Gordon Burditt wrote:
>>> Adding garbage collection would break a large amount of existing code.
>>>
>>
>> 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.
>
> Jacob, what rules would have to be added for application writers
> to use the GC in lcc-win besides the C standard and "don't invoke
> undefined behavior"?  Hint:  the answer is not "none".  And that's
> not intended as a put-down of lcc's GC or GC in general.
>
> Or, to put it another way which I'm sure you will still think of
> as a personal attack, list the things an application programmer
> could do to break GC that no sane programmer would do (someone will
> come up with a sane-sounding reason for doing it anyway) but the C
> standard still allows.  If the C standard calls it undefined behavior
> on the part of the application, GC is off the hook.
>
> I'll define "break GC" as any one or more of the following:
> - Collecting non-garbage
> - Aborting the program with things like segfaults.
> - A 1,000,000% slowdown
> - A GC so conservative it never collects anything.
>

in my case, the policy is basically just to give code the choice.
if it wants to use malloc, it can use malloc;
if it wants to use the GC, it can use the GC.

the GC wont generally trace through memory allocated via malloc though.
in my case, there is a "gcmalloc()" call, which is behaviorally similar 
to malloc (it wont automatically release the memory), except that the GC 
will trace through it.

putting pointers to malloc-managed memory in GC-managed objects works, 
just the GC will ignore them.

it is possible to register behavior hooks with the GC to allow 
custom-managed memory regions.


usually, the GC wont collect anything until after a certain amount of 
memory is used (can be set by the program), so if the app keeps its 
memory use below this limit, the GC wont run (this currently leads to a 
case of setting the limit at something like 1GB, which makes the GC 
running, except in cases where the app "springs a leak" fairly unlikely).


> I'm pretty sure that writing pointers to a (potentially terabyte)
> temporary file, erasing the pointers from memory, and later reading
> the pointers back from the file (all done by the same run of the
> same program) will either confuse or horribly slow down GC.  And I
> think that's perfectly OK with the C standard.

actually, more likely, it will become timing dependent:
if the GC runs during the time the pointers no longer exist, the objects 
may be freed;
if it does not, nothing happens (the pointers will just come back in 
pointing at the same objects).

in the case where the pointers are read back in for objects which have 
been freed, then essentially they are just dangling pointers (and the GC 
will either ignore them, or treat them as if they point to whatever new 
object was allocated at that address).


this case only really matters if the GC is being used to replace malloc 
or similar.

otherwise, a person could declare that the case of temporarily hiding 
and then restoring pointers is itself undefined-behavior.


>>> Often the bottom couple of bits of pointers to memory with known
>>> alignment properties will be used to store information (the pointer than
>>> being and'd with ~0x3ul or similar prior to dereferencing).
>>>
>>
>> ??? That is not the case with the GC used by lcc-win.
>
> I take that to mean:  often an application program will abuse the bottom
> couple of bits of pointers to memory with known alignment properties to
> store information, and this will break the GC.  I think doing that to
> pointers invokes undefined behavior, at least if you do stuff like
> 	void *ptr;
>
> 	ptr |= 3;
> or 	ptr &= ~3;
>
> so the GC has a perfectly good excuse for breaking.
>

my GC will handle this case just fine (my GC is more conservative, and 
so will by-default treat a pointer to anywhere in the object as if it 
were a GC reference). likewise, most GC operations will accept these 
pointers as well, and there is also a "gcGetBase()" operation mostly 
specially for this case: it allows taking a pointer into an object and 
getting the starting address of the object.


I don't know how Boehm handles it exactly, but IIRC there are script VMs 
which use Boehm and use similar tagging schemes.


I don't personally use this sort of tagging in my VM, instead having the 
GC keep track of the type, so whenever the VM needs to do something, it 
will fetch the type-name for an object, or maybe fetch an associated 
type-vtable (the VM has tables of function-pointers used to represent 
common operations on objects of various types).

note that there is also a Class/Instance OO system, but this uses its 
own independent vtables, and these objects exist as a single type from 
the POV of the GC.


>>> Many code protection methods rely on storing pointers xor'd with an
>>> obfuscating mask. GCs are not sophisticated enough to track such pointers.
>
> Code protection methods are designed to break the application, but
> the C standard doesn't forbid that.
>

simple: label the case of XOR'ed pointers + GC'ed objects as undefined.


> I'm not sure the C standard allows that specific method of disguising
> pointers, but I think you are allowed to format a pointer with
> sprintf() and %p, erase the original pointer, then later feed the
> buffer sprintf() wrote into sscanf() and %p, and get back the same
> pointer.  While it's in text form, you could do all sorts of things
> to it (encrypt, store it in a file, etc.) , as long as it eventually
> gets back to the original text.
>

possible, but this case can also be labeled as undefined with GC 
objects, or maybe, it can be restricted to certain cases, such as it is 
only allowed if the objects are pinned/locked beforehand, or if they 
were allocated either with malloc or a malloc-like call (and so will not 
be implicitly freed).


>> Yes, that kind of code shouldn't be used with a GC.
>
> People want to know how to recognize "that kind of code" and not
> try to use GC with it, rather than trying it and figuring it out
> the hard way.  And I don't really see a "don't disguise pointers"
> rule as being too onerous if you can clearly define what *ISN'T*
> disguised.  Probably 99.9% of programs would need no change.
>

in my case, it is more like:
pointers stored in global variables are visible (1);
pointers stored in stack variables are visible (2);
pointers stored in other GC managed objects.


1: on both Windows and Linux, the GC will walk the list of loaded 
modules and scan the ".data" and ".bss" sections and similar. this also 
includes any "static" variables within functions.

2: this can be a little harder. in my case, the GC supplies its own 
thread-creation functions, but it is possible to do so without doing 
this (for example, Boehm walks the OS thread list AFAIK). there is a 
difficulty with knowing the exact stack address on WoW64 targets (an 
issue for Boehm AFAIK), but my GC uses a different strategy: it just 
scans the stack until either the known limit is encountered, or Windows 
throws a SEH exception (when the scan function tries to scan into an 
uninitialized guard page), which the function catches and handles.


>>> And what is the gain?
>>
>> The gain is that instead of loosing endless hours tracking that dangling
>> pointer in the debugger you can concentrate on your application instead.
>
> Oh, yes, another rule for a working GC is that the GC has to
> occasionally actually collect some garbage if there's any around
> to collect.  It doesn't have to catch everything immediately, but
> code like:
>
> #define malloc(x) gc_malloc(x)
> int main(void)
> {
> 	while(malloc(6)) { /* loop */ }
> }
> shouldn't terminate the loop because malloc() eventually returns NULL
> due to insufficient collection of garbage.
>
>

usually what happens in this case is that the caller thread will block 
until the GC thread can run and finish (running out of memory triggers 
an immediate GC).

BGB <cr88192@hotmail.com> writes:

> On 7/21/2012 4:32 AM, Nobody wrote:
>> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>>
>>> Hi Can anyone explain why C has added support for pthreads, while NOT
>>> adding support for garbage collection?
>>
>> GC requires a "walled garden", which C isn't.
>>
>> You can't just "add support" for GC, you have to design the language
>> around the ability to enumerate references.
>>
>
> actually, it can be done, but mostly in the form of conservative GCs,
> such as Boehm.

People are, I think, talking at cross purposes.  Those who say "it can
be done" mean it can be done in a way that works for some (possibly
large) set of programs.  Those that say it can't be done mean that there
are correct C program which will break when linked, unchanged, against a
collecting implementation of malloc.

The discussion would involve much less pointless back-and-forth if
everyone started out by agreeing that it can work for a lot of programs
but it can't work for all programs.  The debate could then be about the
kinds of program for which GC might or might not be useful.

<snip>
-- 
Ben.

Le 21/07/12 15:57, Gordon Burditt a �crit :
> Jacob, what rules would have to be added for application writers
> to use the GC in lcc-win besides the C standard and "don't invoke
> undefined behavior"?  Hint:  the answer is not "none".  And that's
> not intended as a put-down of lcc's GC or GC in general.

1) Do not hide pointers to the collector, i.e. the collector will NOT 
search the window extra bytes (for instance) for pointers, or the hard
disk. If you need to XOR pointers to hide them do not use the collector
either.

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.

That's all.

jacob

Le 21/07/12 15:57, Gordon Burditt a �crit :
> - Collecting non-garbage
> - Aborting the program with things like segfaults.
> - A 1,000,000% slowdown
> - A GC so conservative it never collects anything.

You can collect non garbage when you hide the pointers
from the collector using XOR. Then the collector will
assume that all the pointers not referenced are free
and havoc will ensue.

Also, if you always keep pointers to everything never setting them to
NULL, and all pointers are global (or the roots are in the main()
function, the collector will never collect anything.

For instance a global list will never be collected if its root is a
global pointer. To collect that you have to set that pointer to NULL.

On 7/21/2012 11:38 AM, Ben Bacarisse wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/21/2012 4:32 AM, Nobody wrote:
>>> On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:
>>>
>>>> Hi Can anyone explain why C has added support for pthreads, while NOT
>>>> adding support for garbage collection?
>>>
>>> GC requires a "walled garden", which C isn't.
>>>
>>> You can't just "add support" for GC, you have to design the language
>>> around the ability to enumerate references.
>>>
>>
>> actually, it can be done, but mostly in the form of conservative GCs,
>> such as Boehm.
>
> People are, I think, talking at cross purposes.  Those who say "it can
> be done" mean it can be done in a way that works for some (possibly
> large) set of programs.  Those that say it can't be done mean that there
> are correct C program which will break when linked, unchanged, against a
> collecting implementation of malloc.
>

and, I wasn't thinking about replacing "malloc()" in the first place, 
rather my GC works via its own calls ("gcalloc()", "gctalloc()", 
"gcmalloc()", "gcfree()", ...).

in this case, linking most C programs unchanged against the GC wouldn't 
change or break anything, but they wouldn't be using the GC in this case 
either...


> The discussion would involve much less pointless back-and-forth if
> everyone started out by agreeing that it can work for a lot of programs
> but it can't work for all programs.  The debate could then be about the
> kinds of program for which GC might or might not be useful.
>

or, possibly, what exact form the GC would take in the first place...

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=91=D7=AA,=
 21 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 17:38:12 UTC+1, =D7=9E=D7=90=D7=AA =
Ben Bacarisse:
> BGB <cr88192@hotmail.com> writes:
>=20
> People are, I think, talking at cross purposes.  Those who say 'it can
> be done' mean it can be done in a way that works for some (possibly
> large) set of programs.  Those that say it can't be done mean that there
> are correct C program which will break when linked, unchanged, against a
> collecting implementation of malloc.
>=20
In C a pointer is valid if saved to a file in binary form then read back in=
 again. It's invalid if read back in to an second instance of the program. =
So the standard needs a tweak to make the first situation also invalid.
I don't see that as a problem, except for very specialised memory paging so=
ftware that lives deep down in the bowels of the operating system. That's g=
enerally written in a non-standard version of C anyway.
=20

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> בתאריך יום שבת, 21 ביולי 2012 17:38:12 UTC+1, מאת Ben Bacarisse:
>> BGB &lt;cr88192@hotmail.com&gt; writes:
>> 
>> People are, I think, talking at cross purposes.  Those who say 'it can
>> be done' mean it can be done in a way that works for some (possibly
>> large) set of programs.  Those that say it can't be done mean that there
>> are correct C program which will break when linked, unchanged, against a
>> collecting implementation of malloc.
>> 
> In C a pointer is valid if saved to a file in binary form then read
> back in again. It's invalid if read back in to an second instance of
> the program. So the standard needs a tweak to make the first situation
> also invalid.

Why?  What would be the benefit?

<snip>
-- 
Ben.

On Sat, 21 Jul 2012 20:13:28 +0100, Ben Bacarisse wrote:

>> In C a pointer is valid if saved to a file in binary form then read back
>> in again. It's invalid if read back in to an second instance of the
>> program. So the standard needs a tweak to make the first situation also
>> invalid.
> 
> Why?  What would be the benefit?

What would be the benefit in writing a pointer to a file, or to making
that invalid?

Writing a pointer to a file may be useful for virtual memory systems such
as that used by the Win16 API.

Forbidding writing pointers to files would eliminate one possible
mechanism whereby "transparent" GC would fail.

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:

> On Jul 20, 10:14 pm, Jase Schick <nos...@nospam.com> wrote:
>> 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.
>
> 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.

I  believe that  is consequent  to a  confluence of  (a)  wanting the
environments on  the iPhone and MacOS  to be the same,  (b) needing a
certain level of real-time response on the iPhone, and (c) adopting a
different approach to resource management that allows reference
counting to be used rather than general GC.

It isn't hard to write a high-performance, general-purpose GC.  It's
much harder to write a high-performance GC that observes severe
real-time constraints.

> And sorry to say, but C wasn't designed with garbage collection in
> mind.

But that doesn't precude GC being either feasible or practical in
a C environment.

Quentin Pope <qp19433@hotmail.NOSPAM.com> writes:

> On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
>> Le 20/07/12 23:14, Jase Schick a @C3{A9}crit :
>>> 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 lcc-win compiler offers a garbage collector (Boehm's) in its
>> standard distribution. It is a very useful feature, used for instance in
>> the debugger of lcc-win, in the IDE and several other applications. Of
>> course it is used by many of the people that have downloaded lcc-win
>> (more than 1 million)
>
> [snip]
>
> And what is the gain? With careful programming, there is no need 
> whatsoever for this stupid overhead.

Actual measurements show otherwise.

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

>  Quentin Pope:
>> 
>> 
>> Often the bottom couple of bits of pointers to memory with known 
>> alignment properties will be used to store information (the pointer than 
>> being anded with ~0x3ul or similar prior to dereferencing).
>> 
>> Many code protection methods rely on storing pointers xored with an 
>> obfuscating mask. GCs are not sophisticated enough to track such pointers.
>
> [snip] most garbage collectors are unacceptably inefficient for high
> performance routines.  [snip]

Folklore.  Measurements of real programs using, eg, the Boehm collector,
show macro-scale performance similar to, or better than, the same
program using manual rather than automatic reclamation.  Micro-scale
"efficiencies" don't always translate into improvements in macro-scale
performance, and often quite the contrary.  Furthermore the use of
automatic reclamation (aka "GC") doesn't preclude the use of special
purpose allocators for selected critical code paths, which can be
accommodated easily without having to circumvent the larger GC
framework.

Nobody <nobody@nowhere.com> writes:

> On Sat, 21 Jul 2012 20:13:28 +0100, Ben Bacarisse wrote:
>
>>> In C a pointer is valid if saved to a file in binary form then read back
>>> in again. It's invalid if read back in to an second instance of the
>>> program. So the standard needs a tweak to make the first situation also
>>> invalid.
>> 
>> Why?  What would be the benefit?
>
> What would be the benefit in writing a pointer to a file, or to making
> that invalid?

To making it invalid.  That seems to be the suggesting that Malcolm is
making.

> Writing a pointer to a file may be useful for virtual memory systems such
> as that used by the Win16 API.
>
> Forbidding writing pointers to files would eliminate one possible
> mechanism whereby "transparent" GC would fail.

Right, but it's just one way, and not (in my experience at least) the
most common.

I can see where I went wrong though.  I should have said "is the benefit
really worth it?" because I can see a minuscule benefit, just not one
that could drive a change to the language.

-- 
Ben.

Tim Rentsch <txr@alumni.caltech.edu> writes:
>Folklore.  Measurements of real programs using, eg, the Boehm collector,
>show macro-scale performance similar to, or better than, the same
>program using manual rather than automatic reclamation.  Micro-scale

  When one has nested lifetimes of objects, life is simple: one can
  use automatic storage. The problems begin when lifetimes are dynamic,
  which usually means that to keep track of the objects at all, one
  will build some kind of graph. When that graph is a tree and the
  lifetimes of subtrees do not exceed the lifetime of their supertrees,
  subtrees can be free whenever their supertree is freed, which often
  is still quite simple. But when the graph has a more general form,
  one usually has to implement some form of reference counting or
  marking scheme, which effectively is a garbage collector (Greenspun's
  tenth law).

  Some notes I have collected on the subject (repost):

      �There were two versions of it, one in Lisp and one in
      C++. The display subsystem of the Lisp version was faster.
      There were various reasons, but an important one was GC:
      the C++ code copied a lot of buffers because they got
      passed around in fairly complex ways, so it could be quite
      difficult to know when one could be deallocated. To avoid
      that problem, the C++ programmers just copied. The Lisp
      was GCed, so the Lisp programmers never had to worry about
      it; they just passed the buffers around, which reduced
      both memory use and CPU cycles spent copying.�

<XNOkd.7720$zx1.5584@newssvr13.news.prodigy.com>

      �A lot of us thought in the 1990s that the big battle would
      be between procedural and object oriented programming, and
      we thought that object oriented programming would provide
      a big boost in programmer productivity. I thought that,
      too. Some people still think that. It turns out we were
      wrong. Object oriented programming is handy dandy, but
      it's not really the productivity booster that was
      promised. The real significant productivity advance we've
      had in programming has been from languages which manage
      memory for you automatically.�

http://www.joelonsoftware.com/articles/APIWar.html

      �[A]llocation in modern JVMs is far faster than the best
      performing malloc implementations. The common code path
      for new Object() in HotSpot 1.4.2 and later is
      approximately 10 machine instructions (data provided by
      Sun; see Resources), whereas the best performing malloc
      implementations in C require on average between 60 and 100
      instructions per call (Detlefs, et. al.; see Resources).
      And allocation performance is not a trivial component of
      overall performance -- benchmarks show that many
      real-world C and C++ programs, such as Perl and
      Ghostscript, spend 20 to 30 percent of their total
      execution time in malloc and free -- far more than the
      allocation and garbage collection overhead of a healthy
      Java application (Zorn; see Resources).�

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-jw22JavaUrbanLegends

      �Perhaps the most important realisation I had while developing 
      this critique is that high level languages are more important 
      to programming than object-orientation. That is, languages 
      which have the attribute that they remove the burden of 
      bookkeeping from the programmer to enhance maintainability and 
      flexibility are more significant than languages which just 
      add object-oriented features. While C++ adds object-orientation 
      to C, it fails in the more important attribute of being high 
      level. This greatly diminishes any benefits of the 
      object-oriented paradigm.�

http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index005.htm

      �The garbage collector in contemporary JVMs doesn't touch most
      garbage at all. In the most common collection scenario, the JVM
      figures out what objects are live and deals with them exclusively
      -- and most objects die young. So by the time they get to garbage
      collection, most objects that have been allocated since the last
      garbage collection are already dead. The garbage collector avoids
      a lot of work it would have to do if it were doing it one piece
      at a time. Similarly, the JVM can optimize away many object
      allocations.�
      
http://java.sun.com/developer/technicalArticles/Interviews/goetz_qa.html      

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=91=D7=AA,=
 21 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 23:31:16 UTC+1, =D7=9E=D7=90=D7=AA =
Tim Rentsch:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>=20
> [snip] most garbage collectors are unacceptably inefficient for high
> performance routines.  [snip]
>=20
> Folklore.  Measurements of real programs using, eg, the Boehm collector,
> show macro-scale performance similar to, or better than, the same
> program using manual rather than automatic reclamation. =20
>
I'm sceptical about this. Most "real" programs consist of logically often c=
omplex but in run time terms fairly light layers of program-specific code, =
which calls library routines to do the processor-intensive work. If you jus=
t measure the program-specific code, then you'll find that memory managemen=
t isn't a big factor in the overall performance. But the resuable, processo=
r- intensive components are themselves mainly written in C.

I don't usually write programs like that, however. Normally my programs spe=
nd most of their time in routines written by me, doing heavy processing.

On 21 Jul 2012 22:46:48 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >Folklore.  Measurements of real programs using, eg, the Boehm
> >collector, show macro-scale performance similar to, or better than,
> >the same program using manual rather than automatic reclamation.
> >Micro-scale
>=20
>   When one has nested lifetimes of objects, life is simple: one can
>   use automatic storage. The problems begin when lifetimes are
> dynamic, which usually means that to keep track of the objects at
> all, one will build some kind of graph. When that graph is a tree and
> the lifetimes of subtrees do not exceed the lifetime of their
> supertrees, subtrees can be free whenever their supertree is freed,
> which often is still quite simple. But when the graph has a more
> general form, one usually has to implement some form of reference
> counting or marking scheme, which effectively is a garbage collector
> (Greenspun's tenth law).
>=20
>   Some notes I have collected on the subject (repost):
>=20
>       =C2=BBThere were two versions of it, one in Lisp and one in
>       C++. The display subsystem of the Lisp version was faster.
>       There were various reasons, but an important one was GC:
>       the C++ code copied a lot of buffers because they got
>       passed around in fairly complex ways, so it could be quite
>       difficult to know when one could be deallocated. To avoid
>       that problem, the C++ programmers just copied. The Lisp
>       was GCed, so the Lisp programmers never had to worry about
>       it; they just passed the buffers around, which reduced
>       both memory use and CPU cycles spent copying.=C2=AB

This is true if c++ programmers didn't use smart pointers.
With compacting garbage collector copying is done under the hood.

>=20
> <XNOkd.7720$zx1.5584@newssvr13.news.prodigy.com>
>=20
>       =C2=BBA lot of us thought in the 1990s that the big battle would
>       be between procedural and object oriented programming, and
>       we thought that object oriented programming would provide
>       a big boost in programmer productivity. I thought that,
>       too. Some people still think that. It turns out we were
>       wrong. Object oriented programming is handy dandy, but
>       it's not really the productivity booster that was
>       promised. The real significant productivity advance we've
>       had in programming has been from languages which manage
>       memory for you automatically.=C2=AB

Why? Programmer don;t have to write free(p) while close(fd) is
still needed ;)

>=20
> http://www.joelonsoftware.com/articles/APIWar.html
>=20
>       =C2=BB[A]llocation in modern JVMs is far faster than the best
>       performing malloc implementations. The common code path
>       for new Object() in HotSpot 1.4.2 and later is
>       approximately 10 machine instructions (data provided by
>       Sun; see Resources), whereas the best performing malloc
>       implementations in C require on average between 60 and 100
>       instructions per call (Detlefs, et. al.; see Resources).
>       And allocation performance is not a trivial component of
>       overall performance -- benchmarks show that many
>       real-world C and C++ programs, such as Perl and
>       Ghostscript, spend 20 to 30 percent of their total
>       execution time in malloc and free -- far more than the
>       allocation and garbage collection overhead of a healthy
>       Java application (Zorn; see Resources).=C2=AB

This is not true. While performance of allocations with GC=20
is same as malloc (or faster), performance of cleaning objects
is where GC fails...
Problem is that while free(p) is pretty fast and doesn't require
anything special, GC needs to stop whole program scan memory
fro references, perform clean up and after that update all
references of blocks that are eventually moved.
It is not that bad with single process but actually=20
it is faster to have multiple processes than multiple threads
since per process GC is faster than per songle GC pewr multiple
threads....
There is also problems with memory trashing since GC has
to scan memory...

>=20
> http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=3Dd=
gr-jw22JavaUrbanLegends
>=20
>       =C2=BBPerhaps the most important realisation I had while developing=
=20
>       this critique is that high level languages are more important=20
>       to programming than object-orientation. That is, languages=20
>       which have the attribute that they remove the burden of=20
>       bookkeeping from the programmer to enhance maintainability and=20
>       flexibility are more significant than languages which just=20
>       add object-oriented features. While C++ adds object-orientation=20
>       to C, it fails in the more important attribute of being high=20
>       level. This greatly diminishes any benefits of the=20
>       object-oriented paradigm.=C2=AB
>=20
> http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index005.htm
>=20
>       =C2=BBThe garbage collector in contemporary JVMs doesn't touch most
>       garbage at all. In the most common collection scenario, the JVM
>       figures out what objects are live and deals with them
> exclusively -- and most objects die young. So by the time they get to
> garbage collection, most objects that have been allocated since the
> last garbage collection are already dead. The garbage collector avoids
>       a lot of work it would have to do if it were doing it one piece
>       at a time. Similarly, the JVM can optimize away many object
>       allocations.=C2=AB
>      =20
> http://java.sun.com/developer/technicalArticles/Interviews/goetz_qa.html =
    =20
>=20

 Performance problems in Confluence, and in rarer circumstances for
 JIRA, generally manifest themselves in either:

 frequent or infrequent periods of viciously sluggish responsiveness,
 which requires a manual restart, or, the application eventually and
 almost inexplicably recovers some event or action triggering a
 non-recoverable memory debt, which in turn envelops into an
 application-fatal death spiral (Eg. overhead GC collection limit
 reached, or Out-Of-Memory). generally consistent poor overall
 performance across all Confluence actions

https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+=
Issues

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> >  Quentin Pope:
> >> 
> >> 
> >> Often the bottom couple of bits of pointers to memory with known 
> >> alignment properties will be used to store information (the pointer than 
> >> being anded with ~0x3ul or similar prior to dereferencing).
> >> 
> >> Many code protection methods rely on storing pointers xored with an 
> >> obfuscating mask. GCs are not sophisticated enough to track such pointers.
> >
> > [snip] most garbage collectors are unacceptably inefficient for high
> > performance routines.  [snip]

> Folklore.  Measurements of real programs using, eg, the Boehm collector,
> show macro-scale performance similar to, or better than, the same program
> using manual rather than automatic reclamation.

What I suspect it showed was that Boehm's internal memory allocator was more
efficient than the systems' malloc/free, not that GC can be more performant
than manual management.

I base this interpretation off of a little Googling and the description of
this list creation/destruction example:

	When running Listing 1 and similar programs on GNU/Linux, I've seen
	the Boehm collector perform 1.69 times faster than malloc/free; on
	OpenBSD, more than twice as fast; and on Microsoft Windows NT 4,
	more than 13 times faster.

	-- http://www.drdobbs.com/the-boehm-collector-for-c-and-c/184401632

The notion that GC can be faster than manual management is significantly
more dubious than the claim that JVMs can be faster than compiled code.
Unlike the JVM claim, I can't think of a single thing a GC could do better
than manual management. Perhaps run a concurrent thread in the background,
but then it's not really faster in terms of cpu time. I don't imagine that
particular division of labor is the most efficient, either.

People always like to bring out the example of Azul's Zing collector. But
Azul orginally wrote their collector to run on specialized Java processors
with a hardware memory architecture tailored to work with the GC. Migrating
their techniques over to x86 requires a significant amount of run time work
and paging tricks. It's concurrent but not particularly fast. This explains
why Azul has subsisted on a regular diet of VC injections instead of revenue
or acquistion offers from IBM, Microsoft, Sun, or Oracle.

Bottom line: GC, like JIT'ing, requires significantly more work. That's a
huge hurdle to overcome, and it shouldn't surprise anyone that it typically
tends to be slower than similarly sophisticated alternatives.

You could argue that good GC is better than bad manual management, but
memory management isn't exactly a bottleneck for most programs, at least not
in a way that is easily abstracted and optimized away using generalized
algorithms. So not only does GC have more work to do, but there's not much
profit to be had.

You could argue that GC solves resource leaks--a type of performance
problem--but the vast majority of resource problems I've seen on my projects
are issues with slow GC reclamation and finalizer headaches. Fixing actual
leaks in C code is far more straight forward than turning knobs on a GC. And
while GC technology has improved considerably over the years, its not like C
tools and environments stopped evolving. GCs and JVMs are perpetually on the
brink of surpassing the old, stodgy techniques. And they'd beat them, too,
if it weren't for those meddling kids improving the competition.

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> >Folklore.  Measurements of real programs using, eg, the Boehm collector,
> >show macro-scale performance similar to, or better than, the same
> >program using manual rather than automatic reclamation.  Micro-scale

>   When one has nested lifetimes of objects, life is simple: one can
>   use automatic storage. The problems begin when lifetimes are dynamic,
>   which usually means that to keep track of the objects at all, one
>   will build some kind of graph. When that graph is a tree and the
>   lifetimes of subtrees do not exceed the lifetime of their supertrees,
>   subtrees can be free whenever their supertree is freed, which often
>   is still quite simple. But when the graph has a more general form,
>   one usually has to implement some form of reference counting or
>   marking scheme, which effectively is a garbage collector (Greenspun's
>   tenth law).

>   Some notes I have collected on the subject (repost):

<snip examples>

Not sure whether it's a composition fallacy, or the fallacy of hasty
generalization, but regardless you can post all the examples in the world
(not that any of those were particularly persuasive) and it's still not
going to make automated GC faster.

You can describe compacting and generational collection in intricate detail;
you can show functional equivalence between automated GC and manual memory
management; you can do all of these things and more; and automated GC will
still not become faster.

It's like JITing. You can show me all the examples in the world where JITing
executes code faster than AoT compiled C or Fortran code. And yet, on
average, it just isn't faster. It just... isn't.

I don't even understand why people bother arguing this, because I've yet to
meet a person who would contend that if they replaced all of the
applications they presently use--particularly those in C--with, say, Java
equivalents, they'd have a faster system overall.

This isn't a question of computational complexity. The run time and space
behaviors are of the same order. But the fixed costs to automated GC are
considerable, and the gains de minimis. Most of the ingenuity goes into
ameliorating the reclamation costs; costs which are often absent in simpler
schemes, especially if the author puts any thought into the organization of
his data structures.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>Folklore.  Measurements of real programs using, eg, the Boehm collector,
>>show macro-scale performance similar to, or better than, the same
>>program using manual rather than automatic reclamation.  Micro-scale
>
>   [snip]
>
>   Some notes I have collected on the subject (repost):  [snip]

A nice collection of quotes.  Thank you for reposting them.

Le 22/07/12 07:38, William Ahern a �crit :
> <snip examples>
>
> Not sure whether it's a composition fallacy, or the fallacy of hasty
> generalization, but regardless you can post all the examples in the world
> (not that any of those were particularly persuasive) and it's still not
> going to make automated GC faster.

In other words, no matter how much evidence is accumulated that you are 
wrong you are not going to believe it because...

Well, of course: You KNOW you are right!

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

>  Tim Rentsch:
>> Malcolm McLean &lt;malcolm.mclean5@btinternet.com&gt; writes:
>> 
>> [snip] most garbage collectors are unacceptably inefficient for high
>> performance routines.  [snip]
>> 
>> Folklore.  Measurements of real programs using, eg, the Boehm collector,
>> show macro-scale performance similar to, or better than, the same
>> program using manual rather than automatic reclamation.  
>
> I'm sceptical about this.  Most "real" programs consist of
> logically often complex but in run time terms fairly light
> layers of program-specific code, which calls library routines
> to do the processor-intensive work.  If you just measure the
> program-specific code, then you'll find that memory management
> isn't a big factor in the overall performance.  But the
> resuable, processor- intensive components are themselves mainly
> written in C.

The programs I'm talking about were written entirely in C or
a C-ish language (eg, C++ without templates).  Measurements
were done over all executed code, ie, both "program-specific"
code and "library routines" (without drawing any specific
line as to which is which).

> I don't usually write programs like that, however.  Normally my
> programs spend most of their time in routines written by me,
> doing heavy processing.

My first HLL was Fortran, and much of my early programming right
after that was assembly language of various kinds.  I have the
same predispositions against GC and in favor of manual allocation
as most people of that era, I think.

However, all of the cases I'm aware of where actual measurements
of overall performance were made have found that there is no
penalty, or no significant penalty (within, say, 10% overall --
I don't remember an exact figure), for using GC rather than
manual reclamation.  And GC was definitely faster in some cases.

If you have a large program that extensively uses malloc() and
manual reclamation, it would be great to have it converted
to use GC and see what the performance is like.  I would love
to have a counter-point to offer to the GC fans.  Of course,
if you do run some sort of comparison, it's important to try
to make it a fair comparison -- obviously the results can be
slanted one way or the other by choosing how one program is
transformed into the other.  A complete result would include
both an attempt to have a level playing field, and also a
summary of what was done (or not done) to achieve that, as
well as any factors that perhaps should be taken into account
but weren't for one reason or another.  The more examples the
better!  So if you think you have some good examples sitting
back in your code repository, look over them and see which
ones might be good to try out...

>> Jacob, what rules would have to be added for application writers
>> to use the GC in lcc-win besides the C standard and "don't invoke
>> undefined behavior"?  Hint:  the answer is not "none".  And that's
>> not intended as a put-down of lcc's GC or GC in general.
> 
> 1) Do not hide pointers to the collector, i.e. the collector will NOT 
> search the window extra bytes (for instance) for pointers, or the hard
> disk. If you need to XOR pointers to hide them do not use the collector
> either.

Can I count on (unmangled, unencrypted) pointers in auto variables,
even if the compiler puts them in registers, to be found?  How about
register variables?  Function arguments?  If I can't count on those, I
see lots of trouble ahead for programs heavy on linked lists, which
may be in serious need of garbage collection.

How about the return value of a function in code like:
	NODE	*nptr;	/* auto variable */
	...
	nptr = allocatenewnode(....);
if garbage collection happens to be activated (say, by another
thread) just before the return value of allocatenewnode() is stored
in nptr?  Here, allocatenewnode()'s function is to gc_alloc()
something, fill it in with data, and return a pointer to that data.


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

The 1,000,000% slowdown I was thinking of could be the result of
scanning huge disk files (if it attempts such a thing, which is
probably hopeless) or, large amounts of compressed, say, video data
in memory.  This assumes the program wasn't modified to be GC-aware
and it just uses gc_alloc() for everything including huge quantities
of data.

> Le 21/07/12 15:57, Gordon Burditt a écrit :
>> - Collecting non-garbage
>> - Aborting the program with things like segfaults.
>> - A 1,000,000% slowdown
>> - A GC so conservative it never collects anything.
> 
> You can collect non garbage when you hide the pointers
> from the collector using XOR. Then the collector will
> assume that all the pointers not referenced are free
> and havoc will ensue.

So, you make a rule that pointers to GC-memory must be kept in
(a) auto variables,  (you may add or exclude "register variables" here)
(b) static or global variables,
(c) gc_alloc()ed memory, 
(d) function arguments,
or (e) function return values
and they must be in their original binary form.  Violating this causes
undefined behavior.

> Also, if you always keep pointers to everything never setting them to
> NULL, and all pointers are global (or the roots are in the main()
> function, the collector will never collect anything.

Those aren't eligible for collection.  I might have global root pointers
for linked lists, but the nodes I delete out of the list won't have
anything pointing at it.  And if I need to delete the list, I can
assign NULL then.

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?  (Don't look at
stack frames for functions that have already returned.)

> For instance a global list will never be collected if its root is a
> global pointer. To collect that you have to set that pointer to NULL.

"Tim Rentsch" <txr@alumni.caltech.edu> ha scritto nel messaggio
news:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
> If you have a large program that extensively uses malloc() and
> manual reclamation, it would be great to have it converted
> to use GC and see what the performance is like.  I would love
> to have a counter-point to offer to the GC fans.

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

> Of course,
> if you do run some sort of comparison, it's important to try
> to make it a fair comparison -- obviously the results can be
> slanted one way or the other by choosing how one program is
> transformed into the other.

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

> A complete result would include
> both an attempt to have a level playing field, and also a
> summary of what was done (or not done) to achieve that, as
> well as any factors that perhaps should be taken into account
> but weren't for one reason or another.  The more examples the
> better!  So if you think you have some good examples sitting
> back in your code repository, look over them and see which
> ones might be good to try out...

William Ahern <william@wilbur.25thandClement.com> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
>> >  Quentin Pope:
>> >> 
>> >> 
>> >> Often the bottom couple of bits of pointers to memory with known 
>> >> alignment properties will be used to store information (the pointer than 
>> >> being anded with ~0x3ul or similar prior to dereferencing).
>> >> 
>> >> Many code protection methods rely on storing pointers xored with an 
>> >> obfuscating mask. GCs are not sophisticated enough to track such pointers.
>> >
>> > [snip] most garbage collectors are unacceptably inefficient for high
>> > performance routines.  [snip]
>
>> Folklore.  Measurements of real programs using, eg, the Boehm collector,
>> show macro-scale performance similar to, or better than, the same program
>> using manual rather than automatic reclamation.
>
> What I suspect it showed was that Boehm's internal memory allocator was more
> efficient than the systems' malloc/free, not that GC can be more performant
> than manual management.

Measurements were of overall program performance, not just the memory
allocators.  I don't think comparing just time spent in the allocation
(and deallocation) routines is very meaningful, because that ignores
the cost of keeping track (in the case of manual memory management)
of what needs to be kept alive and what can be reclaimed.  Stroustrup
makes a similar point in (I think) one of the C++ books, talking
about comparing general GC to reference-counted "smart" pointers.
(AFAIK he never tried running an actual experiment, just said that
doing a comparison isn't as easy as it might seem.)

> I base this interpretation off of a little Googling and the description of
> this list creation/destruction example:
>
> 	When running Listing 1 and similar programs on GNU/Linux, I've seen
> 	the Boehm collector perform 1.69 times faster than malloc/free; on
> 	OpenBSD, more than twice as fast; and on Microsoft Windows NT 4,
> 	more than 13 times faster.
>
> 	-- http://www.drdobbs.com/the-boehm-collector-for-c-and-c/184401632
>
> The notion that GC can be faster than manual management is significantly
> more dubious than the claim that JVMs can be faster than compiled code.
> Unlike the JVM claim, I can't think of a single thing a GC could do better
> than manual management. [snip]

Simple programs (ie, that don't allocate very much or that have
simple patterns of allocation/deallocation) don't spend much time
in the allocator (ie, in malloc()/free()).  These programs probably
won't be helped by GC, but also (unless there is some sort of
horrible mismatch between the GC and the allocation patterns)
probably won't be hurt much by GC either.

Complex programs -- that allocate a lot, with lots of different
patterns of allocation/deallocation, and that build complicated
data structures in allocated memory -- will spend more time in
malloc()/free(), but also will spend a significant amount of
time keeping track of which memory blocks need to be retained
and which can be freed.  (Alternatively they can act like
Firefox which never seems to free anything...).  As programs
get more complex, the advantage to GC goes up, not because
the low-level routines are faster, but because GC's generally
do a better job of keeping track of what needs to be retained
in the presence of large, heterogeneous collections of allocated
blocks than manually written code does.  Once we know what can
be freed, it's probably pretty much the same if the code that
does the freeing is in free() or part of a GC;  but figuring
out what can be freed is often faster in a GC than in manually
written code (assuming a complex environment), because the GC
code is written with exactly that focus in mind, whereas the
manually written code is likely to be seen more as "administrative
overhead" that has to be done but isn't really part of the
problem being solved.

> Bottom line: GC, like JIT'ing, requires significantly more work. That's a
> huge hurdle to overcome, and it shouldn't surprise anyone that it typically
> tends to be slower than similarly sophisticated alternatives.

It's important to ask what is being compared.  If GC is compared
to just malloc() and free(), that's an apples and oranges comparison,
because it doesn't take into account the code that keeps track of
which blocks are still needed and which can be freed.  At some level
the only comparison that accurately reflects the relative behavior
is one entire program (using manual memory management) against
another entire program (using automated memory management).

> You could argue that good GC is better than bad manual management, but
> memory management isn't exactly a bottleneck for most programs, at least not
> in a way that is easily abstracted and optimized away using generalized
> algorithms. So not only does GC have more work to do, but there's not much
> profit to be had.

On the contrary -- if memory management isn't a bottleneck, then
having automatic management won't have much effect on performance,
but will have a huge effect on productivity.  Software engineering
studies on not having to do manual memory management show productivity
gains in the range of 1.6 to 2.0.  That's a huge factor to give up
for (what is likely to be) a small drop in performance.

> You could argue that GC solves resource leaks--a type of performance
> problem--but the vast majority of resource problems I've seen on my projects
> are issues with slow GC reclamation and finalizer headaches. Fixing actual
> leaks in C code is far more straight forward than turning knobs on a GC. And
> while GC technology has improved considerably over the years, its not like C
> tools and environments stopped evolving. GCs and JVMs are perpetually on the
> brink of surpassing the old, stodgy techniques. And they'd beat them, too,
> if it weren't for those meddling kids improving the competition.

Are you talking about GCs JVM's here, or are these experiences with
other environments?  I'm curious to know more about experiences
other people have had, especially if the context(s) of those
experiences allows some level of comparison against a C or C-like
environment.

"William Ahern" <william@wilbur.25thandClement.com> wrote in message 
news:f7gsd9-ql9.ln1@wilbur.25thandClement.com...

> It's like JITing. You can show me all the examples in the world where 
> JITing
> executes code faster than AoT compiled C or Fortran code. And yet, on
> average, it just isn't faster. It just... isn't.

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.

GC is just another aid to development.  And maybe the speed is not that 
relevant. Or maybe you can concentrate your efforts on algorithms rather 
than minutiae.

-- 
Bartc 

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A8=D7=90=D7=A9=
=D7=95=D7=9F, 22 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 09:37:10 UTC+1, =D7=9E=
=D7=90=D7=AA io_x:
>=20
> 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...
>=20
That's one of the good things about C.

It's pretty standard to write the first version of a C function to allocate=
 a buffer on every pass, then optimise it by allocating the buffer once and=
 reusing it for the life of the program.
Another thing which should be standard but isn't is stack allocation. Very =
often you need this.

double median(const double *x, int N)
{
   double *temp =3D malloc(N * sizeof(double));
   double answer;
   memcpy(temp, x, N * sizeof(double));
   qsort(temp, N, sizeof(double), compfunc);
   answer =3D (N % 2) ? x[N/2] : (x[N/2-1] + x[N/2])/2.0;
   free(temp);
   return answer;
}

we can't easily get rid of temp. But it could go on a stack. it doesn't nee=
d to be resized, and it's got the same lifetime as an auto variable.

Le 22/07/12 09:28, Gordon Burditt a écrit :
>> Le 21/07/12 15:57, Gordon Burditt a écrit :

> So, you make a rule that pointers to GC-memory must be kept in
> (a) auto variables,  (you may add or exclude "register variables" here)
    Registers are obviously looked for roots, so it is safe to store
    pointers in registers
> (b) static or global variables,
    Yes
> (c) gc_alloc()ed memory,
     Yes
> (d) function arguments,
    Yes
> or (e) function return values
   Yes
> and they must be in their original binary form.  Violating this causes
> undefined behavior.
>
Yes

>> Also, if you always keep pointers to everything never setting them to
>> NULL, and all pointers are global (or the roots are in the main()
>> function, the collector will never collect anything.
>
> Those aren't eligible for collection.  I might have global root pointers
> for linked lists, but the nodes I delete out of the list won't have
> anything pointing at it.  And if I need to delete the list, I can
> assign NULL then.
>
Yes. In general it is a good idea doing that even if you do not use the
collector. Suppose you do NOT set it to NULL and then (without a
collector) you free() the list. You have now a dangling pointer, that
is much WORST than a NULL pointer since many functions test for NULL but
can't test for dangling pointers.


> 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?  (Don't look at
> stack frames for functions that have already returned.)
>

No, in general set pointers to NULL when using global variables or
functions that run for very long periods of time. In short lived
functions garbage will be collectible when the function exits so it
is a slight optiization to avoid that.

BUT

Setting a pointer to NUL is such a CHEAP operation (some nanoseconds)
that setting unused pointers ALWAYS to NULL will never affect really
the performance of your program.

Le 22/07/12 09:08, Gordon Burditt a �crit :
> How about the return value of a function in code like:
> 	NODE	*nptr;	/* auto variable */
> 	...
> 	nptr = allocatenewnode(....);
> if garbage collection happens to be activated (say, by another
> thread) just before the return value of allocatenewnode() is stored
> in nptr?  Here, allocatenewnode()'s function is to gc_alloc()
> something, fill it in with data, and return a pointer to that data.

Nothing bad can ever happen because the "allocatenewnode() will have
stored the pointer it received from gc_malloc somewhere and the
collector will see it.

Boehm's collector has been running for YEARS now and it is very stable,
those problems were solved long ago.

On 7/22/2012 5:32 AM, jacob navia wrote:
> Le 22/07/12 09:08, Gordon Burditt a �crit :
>> How about the return value of a function in code like:
>>     NODE    *nptr;    /* auto variable */
>>     ...
>>     nptr = allocatenewnode(....);
>> if garbage collection happens to be activated (say, by another
>> thread) just before the return value of allocatenewnode() is stored
>> in nptr?  Here, allocatenewnode()'s function is to gc_alloc()
>> something, fill it in with data, and return a pointer to that data.
>
> Nothing bad can ever happen because the "allocatenewnode() will have
> stored the pointer it received from gc_malloc somewhere and the
> collector will see it.
>
> Boehm's collector has been running for YEARS now and it is very stable,
> those problems were solved long ago.
>

yep.

Boehm also scans registers, TLS, ..., in addition to globals and the 
stack, ...

raw data also isn't really a big issue either.

On 7/22/2012 3:37 AM, io_x wrote:
> "Tim Rentsch" <txr@alumni.caltech.edu> ha scritto nel messaggio
> news:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>> If you have a large program that extensively uses malloc() and
>> manual reclamation, it would be great to have it converted
>> to use GC and see what the performance is like.  I would love
>> to have a counter-point to offer to the GC fans.
>
> the conter-point is simply this: programmer has to think
> on memory of his/her program...
>
>> Of course,
>> if you do run some sort of comparison, it's important to try
>> to make it a fair comparison -- obviously the results can be
>> slanted one way or the other by choosing how one program is
>> transformed into the other.
>
> 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...
>

yes, but using a GC does not necessarily mean having to give up on 
freeing memory as well (or even the use of customized/specialized memory 
allocators).

for example, memory may still be manually destroyed when it is known 
that it is safe to do so, which can be used as a sort of hint.

it need not be all-or-nothing.


>> A complete result would include
>> both an attempt to have a level playing field, and also a
>> summary of what was done (or not done) to achieve that, as
>> well as any factors that perhaps should be taken into account
>> but weren't for one reason or another.  The more examples the
>> better!  So if you think you have some good examples sitting
>> back in your code repository, look over them and see which
>> ones might be good to try out...
>
>
>
>
>

Tim Rentsch <txr@alumni.caltech.edu> writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
> 
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>Folklore.  Measurements of real programs using, eg, the Boehm collector,
> >>show macro-scale performance similar to, or better than, the same
> >>program using manual rather than automatic reclamation.  Micro-scale
> >
> >   [snip]
> >
> >   Some notes I have collected on the subject (repost):  [snip]
> 
> A nice collection of quotes.  Thank you for reposting them.

He missed this quote regarding Boehm's GC (relative to malloc.free):

"for programs allocating primarily large objects it will be slower."

Which was said by some guy called 'Boehm'.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

On 7/22/2012 4:40 AM, Tim Rentsch wrote:
> William Ahern <william@wilbur.25thandClement.com> writes:
>

<big snip>

>> You could argue that GC solves resource leaks--a type of performance
>> problem--but the vast majority of resource problems I've seen on my projects
>> are issues with slow GC reclamation and finalizer headaches. Fixing actual
>> leaks in C code is far more straight forward than turning knobs on a GC. And
>> while GC technology has improved considerably over the years, its not like C
>> tools and environments stopped evolving. GCs and JVMs are perpetually on the
>> brink of surpassing the old, stodgy techniques. And they'd beat them, too,
>> if it weren't for those meddling kids improving the competition.
>
> Are you talking about GCs JVM's here, or are these experiences with
> other environments?  I'm curious to know more about experiences
> other people have had, especially if the context(s) of those
> experiences allows some level of comparison against a C or C-like
> environment.
>

I am having "generally good" success with a custom written GC (yes, 
primarily with plain C, and primarily native). (granted, there is some 
use of a custom scripting language in the app as well).


technically, I am more using a hybrid strategy, where in cases where I 
can figure out that memory is no longer needed, it is manually freed.

this is mostly because with a heap-use in the range of 500MB to 2GB, 
running a GC cycle may take several seconds. partly, this is also 
because the GC is kind of naive (it is a conservative concurrent 
mark/sweep collector, and will block other threads if they attempt to 
allocate during a GC cycle).

my applications are generally interactive and soft-real-time (so a GC 
pass doesn't usually break stuff, but can still be kind of annoying).

OTOH, if a person were not using GC, they have to hunt-down / find 
nearly all memory leaks, rather than just major/obvious ones (IOW: the 
ones where the application will sit around spewing garbage).


it would also make development harder, since one would likely also have 
to give up on such niceties as dynamic type checking (1), lead to more 
complex handling of strings (the current practice is mostly just to 
treat strings as value types and let the GC deal with them), ...


1: dynamic type-checking is a feature of my GC, where one can pass 
around a pointer to an object, and later ask the GC what type of object 
it is (typically, this type name is given when allocating the memory for 
an object). I settled mostly on what seemed to be the "generally least 
painful" strategy, namely identifying object types via strings 
(canonically restricted to C identifier rules). (theoretically, a person 
can also use numbers, and while potentially slightly more efficient, are 
considerably more problematic to administer in a decentralized manner, 
and as well, a person can use interned the type-names for faster checking).

in many cases, specialized type-checking predicate functions make use of 
optimized checks (though, most of this, and most of the dynamic 
type-system in general, is located in a secondary library and built on 
top of the GC).

technically, yes, dynamic type checking isn't free, but it makes a lot 
of code considerably less effort to write (a person can still primarily 
use static types, leaving dynamic type-checking mostly for the cases 
where it is more convenient). in some ways, it is vaguely comparable to 
using "instanceof" for similar purposes in Java (or "is" in C#).


or such...

On 7/22/2012 9:50 AM, Phil Carmody wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Folklore.  Measurements of real programs using, eg, the Boehm collector,
>>>> show macro-scale performance similar to, or better than, the same
>>>> program using manual rather than automatic reclamation.  Micro-scale
>>>
>>>    [snip]
>>>
>>>    Some notes I have collected on the subject (repost):  [snip]
>>
>> A nice collection of quotes.  Thank you for reposting them.
>
> He missed this quote regarding Boehm's GC (relative to malloc.free):
>
> "for programs allocating primarily large objects it will be slower."
>
> Which was said by some guy called 'Boehm'.
>

it depends on the app.

in many apps, the vast majority of memory allocations are fairly small 
(typically under 200-500 bytes or so), so it makes a lot of sense to 
optimize primarily for smaller objects.

however, many malloc implementations seem to be less effective for small 
objects (resulting in a large amount of heap-bloat and slowdown).


a more effective allocator may end up needing to use several different 
allocation strategies depending on the size of the object, which may 
potentially cost some in terms of raw speed in certain cases.

decided to leave out a more detailed example, as it was more related to 
my own GC's architecture, and not particularly to Boehm (admittedly, I 
haven't really investigated the workings of the Boehm GC in much detail).

but, a simplified/hypothetical example:
1-16 bytes: may use a slab allocator;
17-6143 bytes: uses bitmaps and cells;
6144-262143 bytes: uses a first-fit free-list allocator;
 >= 262144 bytes: allocates raw memory regions.


or such...

On 2012-07-22, BGB <cr88192@hotmail.com> wrote:
> or such...

You keep on saying this. What does it mean?

On Friday, July 20, 2012 4:14:50 PM UTC-5, Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT=20
> adding support for garbage collection? Convenient memory management would=
=20
> be a much greater enhancement than replicating a perfectly good existing=
=20
> library it seems to me.
>=20
> Jase

The main objection to automatic garbage collection in general that I've see=
n is its non-determinism, which can play hell in a realtime system.  The ge=
neral response to *that* is "when's the last time you had to work on a hard=
 realtime 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. =20

Could also be that WG14 felt that the changes necessitated by threading wer=
e enough for one revision, or that the changes necessitated by GC would neg=
atively impact legacy code or be too hard to implement with the current C a=
rchitecture.  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 AG=
C, create a new library or add new functions to stdlib. =20

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

Seebs?  

Ike Naar wrote:
> On 2012-07-22, BGB wrote:
> > or such...
> 
> 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.

Gordon Burditt wrote:
> 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.

On Jul 21, 12:01=A0pm, jacob navia <ja...@spamsink.net> wrote:
> Le 21/07/12 12:23, Quentin Pope a =E9crit :
>
>
>
>
>
> > On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
> >> Le 20/07/12 23:14, Jase Schick a =E9crit :
> >>> 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 lcc-win compiler offers a garbage collector (Boehm's) in its
> >> standard distribution. It is a very useful feature, used for instance =
in
> >> the debugger of lcc-win, in the IDE and several other applications. Of
> >> course it is used by many of the people that have downloaded lcc-win
> >> (more than 1 million)
>
> > Do you never get tired of spamming this group with advertising for your
> > compiler?
>
> > Adding garbage collection would break a large amount of existing code.
>
> 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.
>
> > Often the bottom couple of bits of pointers to memory with known
> > alignment properties will be used to store information (the pointer tha=
n
> > being and'd with ~0x3ul or similar prior to dereferencing).
>
> ??? That is not the case with the GC used by lcc-win.
>
> > Many code protection methods rely on storing pointers xor'd with an
> > obfuscating mask. GCs are not sophisticated enough to track such pointe=
rs.
>
> Yes, that kind of code shouldn't be used with a GC.
>
> > And what is the gain?
>
> The gain is that instead of loosing endless hours tracking that dangling
> pointer in the debugger you can concentrate on your application instead.
>
> > With careful programming, there is no need
> > whatsoever for this stupid overhead.
>
> 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.
>
> 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

On Jul 21, 6:03=A0pm, jacob navia <ja...@spamsink.net> wrote:

> 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

On Jul 24, 8:56=A0am, Philip Lantz <p...@canterey.us> wrote:
> Ike Naar wrote:
> > On 2012-07-22, BGB wrote:

[various allocations stratagies listed]

> > > or such...

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

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

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

On Jul 22, 9:37=A0am, "io_x" <a...@b.c.invalid> wrote:
> "Tim Rentsch" <t...@alumni.caltech.edu> ha scritto nel messaggionews:kfnk=
3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>
> > If you have a large program that extensively uses malloc() and
> > manual reclamation, it would be great to have it converted
> > to use GC and see what the performance is like. =A0I would love
> > to have a counter-point to offer to the GC fans.
>
> the conter-point is simply this: programmer has to think
> on memory of his/her program...
>
> > Of course,
> > if you do run some sort of comparison, it's important to try
> > to make it a fair comparison -- obviously the results can be
> > slanted one way or the other by choosing how one program is
> > transformed into the other.
>
> 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

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=9C=D7=99=
=D7=A9=D7=99, 24 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 09:23:03 UTC+1, =D7=9E=
=D7=90=D7=AA Nick Keighley:
> On Jul 21, 6:03=C2=A0pm, jacob navia 'ja...@spamsink.net' wrote:
>=20
> 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 n=
ot a negligible consumer of resources.

On 7/24/2012 3:23 AM, Nick Keighley wrote:
> On Jul 21, 6:03 pm, jacob navia <ja...@spamsink.net> wrote:
>
>> 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
>

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

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:46f13787-7ff1-4e0d-ac2c-d0f875f03077@m10g2000vbn.googlegroups.com...
On Jul 22, 9:37 am, "io_x" <a...@b.c.invalid> wrote:
> "Tim Rentsch" <t...@alumni.caltech.edu> ha scritto nel
> messaggionews:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>
> > If you have a large program that extensively uses malloc() and
> > manual reclamation, it would be great to have it converted
> > to use GC and see what the performance is like. I would love
> > to have a counter-point to offer to the GC fans.
>
> the conter-point is simply this: programmer has to think
> on memory of his/her program...
>
> > Of course,
> > if you do run some sort of comparison, it's important to try
> > to make it a fair comparison -- obviously the results can be
> > slanted one way or the other by choosing how one program is
> > transformed into the other.
>
> 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

"BartC" <bc@freeuk.com> writes:
>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?

On Jul 24, 1:36=C2=A0pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=9C=D7=
=99=D7=A9=D7=99, 24 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 09:23:03 UTC+1, =D7=
=9E=D7=90=D7=AA Nick Keighley:> On Jul 21, 6:03=C2=A0pm, jacob navia 'ja...=
@spamsink.net' 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 syste=
m. So the garbage collector itself won't take down the system. However it's=
 not a negligible consumer of resources.

I didn't say "video" did I?

On Jul 27, 7:47=A0pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messagg=
ionews:46f13787-7ff1-4e0d-ac2c-d0f875f03077@m10g2000vbn.googlegroups.com...
> On Jul 22, 9:37 am, "io_x" <a...@b.c.invalid> wrote:
>
>
>
>
>
> > "Tim Rentsch" <t...@alumni.caltech.edu> ha scritto nel
> > messaggionews:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>
> > > If you have a large program that extensively uses malloc() and
> > > manual reclamation, it would be great to have it converted
> > > to use GC and see what the performance is like. I would love
> > > to have a counter-point to offer to the GC fans.
>
> > the conter-point is simply this: programmer has to think
> > on memory of his/her program...
>
> > > Of course,
> > > if you do run some sort of comparison, it's important to try
> > > to make it a fair comparison -- obviously the results can be
> > > slanted one way or the other by choosing how one program is
> > > transformed into the other.
>
> > 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.

"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:45ddf962-89c0-4319-9a85-6dfb8817f123@e20g2000vbm.googlegroups.com...
> On Jul 27, 7:47 pm, "io_x" <a...@b.c.invalid> wrote:

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

-- 
Bartc 

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio 
news:45ddf962-89c0-4319-9a85-6dfb8817f123@e20g2000vbm.googlegroups.com...
On Jul 27, 7:47 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel 
> messaggionews:46f13787-7ff1-4e0d-ac2c-d0f875f03077@m10g2000vbn.googlegroups.com...
> On Jul 22, 9:37 am, "io_x" <a...@b.c.invalid> wrote:
>
>
>
>
>
> > "Tim Rentsch" <t...@alumni.caltech.edu> ha scritto nel
> > messaggionews:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>
> > > If you have a large program that extensively uses malloc() and
> > > manual reclamation, it would be great to have it converted
> > > to use GC and see what the performance is like. I would love
> > > to have a counter-point to offer to the GC fans.
>
> > the conter-point is simply this: programmer has to think
> > on memory of his/her program...
>
> > > Of course,
> > > if you do run some sort of comparison, it's important to try
> > > to make it a fair comparison -- obviously the results can be
> > > slanted one way or the other by choosing how one program is
> > > transformed into the other.
>
> > 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.

#people are scared to think on memory: where to allocate where
#deallocate etc why there etc

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.

#my experience is very good in write one malloc function...
#yes i know it is difficult
#but one can see how is used all the memory when, where
#why etc all

Life's too short.

#you say it is difficult: right, i don't know 100 if it is right...
#but for 3-5 years and i as only user i say only: good functions 

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:50169e57$0$13271$4fafbaef@reader2.news.tin.it...
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:45ddf962-89c0-4319-9a85-6dfb8817f123@e20g2000vbm.googlegroups.com...
> On Jul 27, 7:47 pm, "io_x" <a...@b.c.invalid> wrote:
>> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel
>> messaggionews:46f13787-7ff1-4e0d-ac2c-d0f875f03077@m10g2000vbn.googlegroups.com...
>> On Jul 22, 9:37 am, "io_x" <a...@b.c.invalid> wrote:
>> > "Tim Rentsch" <t...@alumni.caltech.edu> ha scritto nel
>> > messaggionews:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>>
>> > > If you have a large program that extensively uses malloc() and
>> > > manual reclamation, it would be great to have it converted
>> > > to use GC and see what the performance is like. I would love
>> > > to have a counter-point to offer to the GC fans.
>>
>> > the conter-point is simply this: programmer has to think
>> > on memory of his/her program...
>>
>> > > Of course,
>> > > if you do run some sort of comparison, it's important to try
>> > > to make it a fair comparison -- obviously the results can be
>> > > slanted one way or the other by choosing how one program is
>> > > transformed into the other.
>>
>> > 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.

> #people are scared to think on memory: where to allocate where
> #deallocate etc why there etc

in few words i spoke against people that like GC because with that
function they have not think on memory allocation-deallocation
where i think the programmer has to think on memory allocation-deallocation
and check memory too

> 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.
>
> #my experience is very good in write one malloc function...
> #yes i know it is difficult

it is not much difficult if one has some book as K&R that show
one malloc() free() implementation
the difficult is make it better-faster whitout errors

> #but one can see how is used all the memory when, where
> #why etc all
>
> Life's too short.

> #you say it is difficult: right, i don't know 100 if it is right...
> #but for 3-5 years and i as only user i say only: good functions

i would see all above too as:
if some function is used many time in code, better reinvent
that function, and malloc is one of them
because i think it is better reduce run-time of extern code:
better my code. Am i not enought humble?

On Jul 20, 7:03=A0pm, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
> On Jul 20, 10:14=A0pm, Jase Schick <nos...@nospam.com> wrote:
>
> > Hi Can anyone explain why C has added support for pthreads, while NOT
> > adding support for garbage collection? Convenient memory management wou=
ld
> > be a much greater enhancement than replicating a perfectly good existin=
g
> > library it seems to me.
>
> 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.

BGB=E6=96=BC 2012=E5=B9=B47=E6=9C=8824=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8CU=
TC+8=E4=B8=8B=E5=8D=8810=E6=99=8255=E5=88=8633=E7=A7=92=E5=AF=AB=E9=81=93=
=EF=BC=9A
> On 7/24/2012 3:23 AM, Nick Keighley wrote:
>=20
> > On Jul 21, 6:03 pm, jacob navia <ja...@spamsink.net> wrote:
>=20
> >
>=20
> >> 2) In modern machines a collector slows down the program for at most
>=20
> >> a milisecond in normal situations, that could be bigger but not much
>=20
> >> bigger since the collector tries to spread out the GC time in each
>=20
> >> allocation.
>=20
> >
>=20
> > whilst that's impressive even a milisecond might matter in some real
>=20
> > time systems
>=20
> >
>=20
>=20
>=20
> hard real-time, maybe.
>=20
> then the usual strategy would be not to use a GC.
>=20
> in any case, it would be best if C preserved the right to choice as to=20
>=20
> whether or not GC is used.
>=20
>=20
>=20
>=20
>=20
> soft real-time is, well, softer. typically, the matter of whether or not=
=20
>=20
> a GC is used can be more left to the impact it may have on the user=20
>=20
> experience. assuming that the GC is not running all the time (this is=20
>=20
> likely only really in pathological conditions), the negative impact is=20
>=20
> fairly small, but may allow delivering a better user experience overall=
=20
>=20
> (while at the same time, preventing slower memory leaks from eventually=
=20
>=20
> crashing the program).
>=20
>=20
>=20
> speed critical code may also refrain from allocating memory or using=20
>=20
> dynamic type-checking as well.
>=20
>=20
>=20
>=20
>=20
> actually, as-is, GC libraries supply a choice as to whether or not GC is=
=20
>=20
> used, apart from people arguing that "there is no choice, since they are=
=20
>=20
> unusable".
>=20
>=20
>=20
> any sort of standard GC would likely still need to preserve choice, and=
=20
>=20
> hopefully not be too far in "lame duck" territory either.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> decided to leave out anecdotes related to my experience plugging my GC=20
>=20
> into the Quake 2 "hunk"-allocator system (basically, memory allocation=20
>=20
> 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 storabl=
e to the hard disk, and perform jobs in a shell way that can be safely exit=
ed in all modules.

It is as difficult as building the OS mmu part.



=20

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);> <#>

On Aug 2, 2:08=A0pm, tom st denis <t...@iahu.ca> wrote:

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

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.

On Aug 2, 3:23=A0pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
> 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

tom st denis wrote:

> 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 o_O
(I suppose the author didn't want to propagate errors.)
Kinda hairy, in my opinion.

tom st denis <tom@iahu.ca> writes:

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

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

On 8/2/2012 8:44 AM, 88888 Dihedral wrote:
> BGB於 2012年7月24日星期二UTC+8下午10時55分33秒寫道：
>> On 7/24/2012 3:23 AM, Nick Keighley wrote:
>>
>>> On Jul 21, 6:03 pm, jacob navia <ja...@spamsink.net> wrote:
>>
>>>
>>
>>>> 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
>>
>>>
>>
>>
>>
>> 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.
>

typically, tracing GC's, such as mark/sweep collectors, incremental 
tricolor collectors, ... are what are commonly used in this case.

usually, the stack and global variables and similar are regarded as 
"roots" and are then searched for object references, making it possible 
to determine which objects are and are-not visible.


reference-counting tends to be a PITA to make work without compiler 
assistance, so is not commonly used as a general purpose GC mechanism.

similarly, given that compacting collectors (such as copy-collectors) 
tend not to really be compatible with C (likewise would require compiler 
support), they are not generally used.


I am not really aware of anyone using persistent storage *as* the GC.

On 7/29/2012 5:14 PM, Stefan Ram wrote:
> "BartC" <bc@freeuk.com> writes:
>> 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?
>

it is worth noting that many larger C or C++ apps also tend to make use 
of GC, in particular, Boehm tends to be popular.


so, it isn't an issue of GC vs no-GC, but rather of C vs Java in particular.

likely, much of the status Java holds is more due to hype, but the 
downside of Java is that it is actually kind of a painful language to 
write code in (once one goes much outside the "there is a library for 
everything" territory, writing actual code in the language tends to be 
awkward and painful, due mostly to its built-in limitations...).

but, for a language that lets the programmer write the code they want to 
write, it starts looking more like C.


to a lesser extent is the VM vs no-VM issue, but sadly, given the way C 
works, it is a language which is a bit harder to run generally within a 
VM, and the alterations needed to make it work more effectively in a VM 
setting would tend to violate the standard (a person could still have a 
language which looks and behaves much like good old C, but would have 
quirks that would likely make it so that the "100% of conforming 
software still works" assumption is no longer upheld, and a person may 
instead be looking at, say, 95% backwards compatibility...).

I have wanted to make a fully VM-managed C for a while, but most of my 
attempts tend to stall out mostly due to the effort this would require, 
and that most of my time/effort is better spent elsewhere in the project 
(and also that most of the power of C is captured well enough by the 
natively compiled variant).

On 7/30/2012 7:05 AM, BartC wrote:
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
> news:45ddf962-89c0-4319-9a85-6dfb8817f123@e20g2000vbm.googlegroups.com...
>> On Jul 27, 7:47 pm, "io_x" <a...@b.c.invalid> wrote:
>
>>> #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.
>

also happened to me before.
in the past I had cases where JIT-compiled BGBScript code was 
outperforming GCC-compiled C code (usually for trivial tests, like 
recursive Fibonacci or doing arithmetic in a loop).

nevermind if this is hardly the usual case. being a VM-based scripting 
language, and currently running as threaded code (almost purely function 
calls back into the C-based interpreter logic), it is generally 
considerably slower than natively compiled C.

(the issue is that a full JIT is terrible to try to maintain in the face 
of a language/VM design that is still a moving target).


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

yeah.


pretty much how I got into writing memory managers originally, was long 
ago off in the land of Linux (although my memory is fuzzy, as it may 
have been on DJGPP+DOS, I forget, this was around the late 90s), I was 
writing some apps that were allocating lots of small strings and 
similar. "malloc()" would chew through memory, and then often cause the 
app to crash as well.

I later devised a solution:
I would allocate a 1MB block of memory, and created a small linked-list 
allocator (the block would have a link to the start of the free-list), 
and used best-fit. I was able to considerably reduce memory-bloat and 
crashes by doing so.

GC started being used on-off early on as well (it has been a long hard 
road getting it "just right" though).

I later improved density by switching from a free-list to fixed-size 
memory cells (originally 8 bytes) and using a bitmap for allocation, and 
improved performance by switching over to first-fit, and capacity (by 
allocating more chunks as-needed).

later on, I switched to 16-byte cells and 4MB chunks, as well as tending 
to fall back to using a different allocation strategy (currently pulling 
the actual memory from malloc) for larger objects (several kB and 
larger), mostly as this tends to be faster (the performance of scanning 
a bitmap for spans of free cells drops off rapidly as the object size 
gets larger).

similarly, free-lists were also devised for the small case as well, 
mostly by daisy-chaining free objects of a particular number of cells 
(used prior to a bitmap-based scan). this handled the case of up to 256 
cells (4kB).

....


actually, I remember much more recently (on WinXP, likely using either 
MinGW or MSVC, I forget) writing an small app which used "malloc()" for 
small strings, and it also chewed through absurd amounts of memory (it 
processed text files, allocating strings for individual tokens, ..., and 
could easily run up against the 3GB process-size limit). so, a custom MM 
still makes some sense here as well.


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

if the object becomes significantly larger than the OS page size (not 
necessarily 1:1 with HW pages, for example Windows uses 4kB HW pages, 
but 64kB OS pages), then the cost overhead of just allocating a raw 
chunk of memory gets much smaller (an only partially-used page is small 
vs the size of the object itself).

[ actually, I have before wondered about bi-level allocation in a 
filesystem, say, where 64 or 256 byte cells are used for smaller files 
(probably by subdividing blocks), and the usual 4kB / 8kB / 16kB blocks 
are used for larger ones, but I have little say over what OS developers 
do, and app-local pseudo-filesystems are of little relevance to OS 
people. (note that the Linux EXT filesystems instead work by typically 
storing small files directly within the "inode" structure, but this 
creates a jump between what will fit within the inode, and what will 
require full disk blocks). ]


but, if smaller, using a full page to allocate a small string is almost 
pure waste.


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

=D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A =D7=99=D7=95=D7=9D =D7=A9=D7=A0=D7=99,=
 30 =D7=91=D7=99=D7=95=D7=9C=D7=99 2012 10:09:41 UTC+1, =D7=9E=D7=90=D7=AA =
Nick Keighley:
> On Jul 27, 7:47=C2=A0pm, "io_x" <a...@b.c.invalid> wrote:
>=20
> Since
> malloc() is suppiled with my C library I've had no compulsion to write
> my own.
>=20
> Life's too short.
>
In Basic Algorithms I covered things like memory allocators, meths library =
routines, Fouruer transforms. Generally you don't have to code these for re=
al. But if you don't know how they work, you've no insight into the isues s=
urrounding their use.
--=20
Basic Algorihtms - a massive C programming resource
http://www.malcolmmcleran.site11.com/www
=20

BGB <cr88192@hotmail.com> writes:
>downside of Java is that it is actually kind of a painful language to 
>write code in

  There is a slight disturbance in what sometimes looks like
  redundant code, such as

if( i instanceof java.lang.CharSequence )
{ java.lang.CharSequence s =( java.lang.CharSequence )i; ... }

  , but in Java SE (standard edition) you can at least write a
  portable GUI program using sockets, regular expressions and
  file system access without external libraries, all of which
  is not possible with the standard C library.

  Java is lacking some features, like closures, but C does not
  have closures either.

>but, for a language that lets the programmer write the code they want to 
>write, it starts looking more like C.

  C is used for core/kernel software, where one wants to have
  direct access to the ABI of the OS or even to hardware or
  when one needs highest performance or realtime response, or
  for small microcontrollers, that do not allow for a large
  runtime.

Am 03.08.2012 13:13, schrieb tom st denis:
> On Aug 2, 3:23 pm, Jens Gustedt <jens.gust...@loria.fr> wrote:
>> 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.

youp, I do

But really don't think of every day's programmer for that, but e.g
people that implement C++'s try/catch mechanism or other such stuff
for higher languages in C.

Said otherwise, deleting setjmp/longjmp from the language is certainly
not an option. It is a core feature.

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

perhaps

I was trying to think on a more realistic line. If you'd want such a
feature, there is nothing essential that would hinder you to implement
it first for auto variables without letting a choice to the
programmer. This can be done without extending the language. It would
have advantages (namely avoid stackoverflow, namely for VLA) and
downsides (a bit of performance loss).

If then you have a system that implements this, runs smoothly without
a bug for some time on a large variety of systems and code, you may
even propose the extension to allow to specify that explicitly, why
not.

Jens

On 8/3/2012 4:20 PM, Stefan Ram wrote:
> BGB <cr88192@hotmail.com> writes:
>> downside of Java is that it is actually kind of a painful language to
>> write code in
>
>    There is a slight disturbance in what sometimes looks like
>    redundant code, such as
>
> if( i instanceof java.lang.CharSequence )
> { java.lang.CharSequence s =( java.lang.CharSequence )i; ... }
>
>    , but in Java SE (standard edition) you can at least write a
>    portable GUI program using sockets, regular expressions and
>    file system access without external libraries, all of which
>    is not possible with the standard C library.
>

note that the omitted context ("once one goes much outside the 'there is 
a library for everything' territory").


or, IOW, where a person has to write a lot of their own logic code, 
without being able to fall back on library functionality (IOW: assume 
there are *no* pre-existing packages or classes to solve a problem, and 
the person has to write all their own code).

on this front, Java gets a bit more painful (vs either C or C++).



>    Java is lacking some features, like closures, but C does not
>    have closures either.
>

newer Java "sort of" has closures.
C also has closures, sort of, if one is willing to live with 
compiler-specific extensions.


>> but, for a language that lets the programmer write the code they want to
>> write, it starts looking more like C.
>
>    C is used for core/kernel software, where one wants to have
>    direct access to the ABI of the OS or even to hardware or
>    when one needs highest performance or realtime response, or
>    for small microcontrollers, that do not allow for a large
>    runtime.
>

or for things like developing non-trivial apps or 3D games or similar...

yes, there is Minecraft, but it is a relative oddity in these regards...

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:71228f71-65d0-47ab-af5e-6a6cbb77c469@googlegroups.com...

> In Basic Algorithms I covered things like memory allocators, meths library 
> routines, Fouruer transforms. Generally you don't have to code these for 
> real. But if you don't know how they work, you've no insight into the 
> isues surrounding their use.
> -- 
> Basic Algorihtms - a massive C programming resource
> http://www.malcolmmcleran.site11.com/www

This site's pretty good too:

http://www.malcolmmclean.site11.com/www/ 

"BartC" <bc@freeuk.com> writes:
> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
> news:71228f71-65d0-47ab-af5e-6a6cbb77c469@googlegroups.com...
> 
> > In Basic Algorithms I covered things like memory allocators, meths
> > library routines, Fouruer transforms. Generally you don't have to
> > code these for real. But if you don't know how they work, you've no
> > insight into the isues surrounding their use.
> > -- 
> > Basic Algorihtms - a massive C programming resource
> > http://www.malcolmmcleran.site11.com/www
> 
> This site's pretty good too:
> 
> http://www.malcolmmclean.site11.com/www/

But does it cover things like meths?

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

"io_x" <a@b.c.invalid> writes:

> "Tim Rentsch" <txr@alumni.caltech.edu> ha scritto nel messaggio
> news:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>> If you have a large program that extensively uses malloc() and
>> manual reclamation, it would be great to have it converted
>> to use GC and see what the performance is like.  I would love
>> to have a counter-point to offer to the GC fans.
>
> the conter-point is simply this: programmer has to think
> on memory of his/her program...

That's not a counter-point, it's a position statement.
To be a counter-point there needs to be some sort of
evidence offered, not just opinion.

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> 
>> > Tim Rentsch <txr@alumni.caltech.edu> writes:
>> >>Folklore.  Measurements of real programs using, eg, the Boehm collector,
>> >>show macro-scale performance similar to, or better than, the same
>> >>program using manual rather than automatic reclamation.  Micro-scale
>> >
>> >   [snip]
>> >
>> >   Some notes I have collected on the subject (repost):  [snip]
>> 
>> A nice collection of quotes.  Thank you for reposting them.
>
> He missed this quote regarding Boehm's GC (relative to malloc.free):
>
> "for programs allocating primarily large objects it will be slower."
>
> Which was said by some guy called 'Boehm'.

That is a good quote to know!  thank you.

On 2012-07-22, io_x <a@b.c.invalid> wrote:
> 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...

It's not opposite because you can build your own gc and tune it endlessly
just like malloc and free.

Your application layer might not control the exact timing of when a given
piece of storage is reclaimed, but that's not the same thing as having no
control whatsoever.

"Tim Rentsch" <txr@alumni.caltech.edu> ha scritto nel messaggio
news:kfnpq5xitl6.fsf@x-alumni2.alumni.caltech.edu...
> "io_x" <a@b.c.invalid> writes:
>
>> "Tim Rentsch" <txr@alumni.caltech.edu> ha scritto nel messaggio
>> news:kfnk3xw1eec.fsf@x-alumni2.alumni.caltech.edu...
>>> If you have a large program that extensively uses malloc() and
>>> manual reclamation, it would be great to have it converted
>>> to use GC and see what the performance is like.  I would love
>>> to have a counter-point to offer to the GC fans.
>>
>> the conter-point is simply this: programmer has to think
>> on memory of his/her program...
>
> That's not a counter-point, it's a position statement.
> To be a counter-point there needs to be some sort of
> evidence offered, not just opinion.

yes it is just what i think, that is so
because i like to see memory leyaout of the routines or
think on constructor-destructor, or find memory leaks
of objects

i not have the evidence for all you
my could be one error...

Buon Giorno