Garbage collection
jacob navia
In an interviw with Dr Dobbs, Paul Jansen explains which languages are
gaining in popularity and which not:
<quote>
DDJ: Which languages seem to be losing ground?
PJ: C and C++ are definitely losing ground. There is a simple
explanation for this. Languages without automated garbage collection are
getting out of fashion. The chance of running into all kinds of memory
problems is gradually outweighing the performance penalty you have to
pay for garbage collection.
<end quote>
lcc-win has been distributing a GC since 2004.
It really helps.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
cr88192
"jacob navia" <ja...@nospam.com> wrote in message
news:fusi33$e0n$1...@aioe.org...
>
> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
> gaining in popularity and which not:
>
> <quote>
> DDJ: Which languages seem to be losing ground?
>
> PJ: C and C++ are definitely losing ground. There is a simple explanation
> for this. Languages without automated garbage collection are getting out
> of fashion. The chance of running into all kinds of memory problems is
> gradually outweighing the performance penalty you have to pay for garbage
> collection.
> <end quote>
>
> lcc-win has been distributing a GC since 2004.
>
> It really helps.
>
I agree...
I have also been using garbage collection in my projects for years with good
success...
I also face people who condemn both garbage collection and C, but I really
like C personally (I am less of a fan of Java personally, even if it has
gained a lot of ground...).
C# may also become a big player, and may in time overpower Java (there are
variables though, I suspect .NET being both a gain and a potential
hinderance at this point in time).
C will likely remain around for a while, but the high-point for C++ may be
starting to pass (C++ is a heavy beast, and losing some of its major selling
points to other languages, may start to fall into disuse much faster than C
does...).
Yunzhong
garbage collection is not just in performance penalty, but that it
introduces uncertainty to the code. It becomes difficult to predict at
what time the garbage collector will start running. In some cases this
behavior simply cannot be tolerated.
jacob navia
In Boehm's GC it will start ONLY when you call malloc().
If you do not call malloc() nothing can happen...
user923005
> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
> gaining in popularity and which not:
Who's Paul Jansen?
> <quote>
> DDJ: Which languages seem to be losing ground?
>
> PJ: C and C++ are definitely losing ground. There is a simple
> explanation for this. Languages without automated garbage collection are
> getting out of fashion. The chance of running into all kinds of memory
> problems is gradually outweighing the performance penalty you have to
> pay for garbage collection.
> <end quote>
>
> lcc-win has been distributing a GC since 2004.
>
> It really helps.
Is lcc-win outselling Microsoft or Intel's compilers?
I guess that most C work is at the embedded level today. I doubt if
we will have garbage collectors running in our toasters any time soon.
Gordon Burditt
>
>It really helps.
In what ways does that implementation violate the standard?
My bet is that it will incorrectly free pieces of allocated memory
when the only references to that memory are in a file (written by
that process and later read back in by the same process). If lcc-win
actually handles this, its performance likely sucks if it has to
scan gigabyte (or worse, terabyte) files for pointer references.
I think the standard also allows, under the right circumstances,
for pointers to be *encrypted*, then stored in a file, and later
read back, decrypted, and used.
Oh, yes, to count as GC, it has to occasionally actually free
something eligible to be freed.
I don't consider this to be a fatal flaw for GC in general or this
implementation in particular, as storing pointers in files is
relatively unusual. But a standards-compliant GC has to deal with
it.
Eric Sosman
> On Apr 25, 5:16 am, jacob navia <ja...@nospam.com> wrote:
>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
>> gaining in popularity and which not:
>
> Who's Paul Jansen?
Google has lots of hits for "Paul Jansen," starting with
a firm that makes piano benches. Adding "Dobbs" to the query
leads us to a Paul Jansen who's the managing director of TIOBE
Software. Never heard of them, but they have something called
the "TIOBE Programming Community Index" that apparently tries
to measure the "popularity of programming languages," but does
so by estimating "their web presence." This they do by running
searches of the form "X programming" for various language names,
and counting the hits.
Sounds like phrenology, doesn't it? Or perhaps astrology?
Maybe we need a new word for this sort of research, something
like "gullibology," or better yet "apology."
Interesting factoid: According to Jansen, COBOL is not
among the top ten most popular languages, having been edged
out by Python -- within the last five years! The Amazing
Grace had more staying power than people thought ...
>> lcc-win has been distributing a GC since 2004.
>>
>> It really helps.
>
> Is lcc-win outselling Microsoft or Intel's compilers?
>
> I guess that most C work is at the embedded level today. I doubt if
> we will have garbage collectors running in our toasters any time soon.
That's why the toast crumbs keep accumulating at the bottom.
Eric Sosman
It's pretty unusual to write pointers out to external
files, but scrambling them in memory is more common (not
entirely kosher, of course, but more common). A trick one
frequently sees is turning a pointer into an integer and
storing a couple of flag bits in the low-order "necessarily
zero because of alignment" positions. The pointer is later
reconstituted by ANDing off the known-zero bits before
dereferencing. Interpreters for LISP commonly do this to
distinguish "atom" pointers from "cons" pointers.
However, this weak form of scrambling probably wouldn't
bollix a C-ish garbage collector. Turn on a few low-order
bits in a pointer, and the GC is likely to see the result as
a pointer "into" rather than "at" some memory block, so
the block itself would still be considered live. Of course,
one can never be entirely sure.
(I once had a truly miserable time with some code that
stored flags in the low-order bits of function pointers. The
code had been developed on a CPU whose instructions were all
four bytes long and aligned on four-byte boundaries, so a
pointer to any function's first instruction always had two
low-order zeroes. I had to port the thing to the VAX, whose
instructions came in many lengths and could start at any
arbitrary byte address ... A truly effective garbage collector
for that code would not have bothered recycling memory; it
would have mulched the source and maybe its author, too!)
Richard
Eric Sosman <Eric....@sun.com> writes:
>> I guess that most C work is at the embedded level today. I doubt if
>> we will have garbage collectors running in our toasters any time soon.
>
> That's why the toast crumbs keep accumulating at the bottom.
Heh. That's funny - no garbage collection. Good one.
santosh
As GC hasn't been defined by the standard yet, we can't say. For all we
know WG14 might decide to excuse GC from scanning for pointers in files
and similar stuff. Right now using a GC is non-conforming simply
because the standard attempts no definition for it.
William Ahern
> Who's Paul Jansen?
When people merely say "embedded", I think it confuses the issue.
The places where C continues to be used, and will continue to be used, are
places where the problem is very well defined, and the solution amenable to
a fixed interface. This happens to be the case for embedded hardware
products, as well as for many elements of more general purpose computing
platforms: SQL databases, libraries or applications implementing
well-defined specifications (XML, HTTP), and other "optimizing" parts of
applications in more higher-level languages, not to mention virtual
machines, etc. C is a simple language, and it can express these solutions
quite readily.
Because of the way software systems are constructed (especially "edge"
systems, like web applications), and because of the growth of the IT sector
(particularly in number of programmers), it's inevitable that C will become
_relatively_ diminished. By itself, of course, this means very little for C.
And I think that when people characterize the C community as "mostly
embedded developers", they fall into the trap of excusing or explaining a
supposed shift; but I don't see a shift in C usage much at all.
Before Java and C# there was Visual Basic and Delphi. There's still Visual
Basic. There are untold numbers of people programming in PHP. I remember
when Cold Fusion came out. Many corporations jumped on it because it
promised managers the ability to repurpose "functional" personnel for doing
"technical" work; i.e. turn your average Joe into a "programmer". There's
nothing wrong w/ that, but when it happens it doesn't mean C is becoming
less popular in the sense that its role is being overcome by other
languages. And there's no reason to think that C is "retreating" to the
hidden world of toaster software anymore than it always has; which is to
say: it's not.
All that's happening is that there are myriad new _types_ of applications,
many of which C is not well suited for. The old _types_ are still there, and
usage is growing in absolute terms. There's no need for a bunker mentality.
Chris Thomasson
> gaining in popularity and which not:
>
> <quote>
> DDJ: Which languages seem to be losing ground?
>
> PJ: C and C++ are definitely losing ground. There is a simple explanation
> for this. Languages without automated garbage collection are getting out
> of fashion. The chance of running into all kinds of memory problems is
> gradually outweighing the performance penalty you have to pay for garbage
> collection.
> <end quote>
>
> lcc-win has been distributing a GC since 2004.
>
> It really helps.
If you need GC, well yes, it would help out a whole lot indeed. As long as
its not mandatory, I see absolutely nothing wrong with including a
full-blown GC in your compiler package.
Gordon Burditt
>> implementation in particular, as storing pointers in files is
>> relatively unusual. But a standards-compliant GC has to deal with
>> it.
>
>As GC hasn't been defined by the standard yet, we can't say. For all we
Yes, we can. GC doesn't have to do anything different from the perspective
of a C program, although for 'real' GC it has to be able to collect some
garbage.
>know WG14 might decide to excuse GC from scanning for pointers in files
>and similar stuff. Right now using a GC is non-conforming simply
>because the standard attempts no definition for it.
No, using GC is allowed under 'as if' rules provided it doesn't make
any mistakes. Similar issues apply to swapping and paging - also not
specifically mentioned by the standard. There are
no rules against things like long pauses, poor performance, or similar
things. However, if GC mistakenly releases memory in use, then
reallocates it or otherwise lets it get scribbled on, it's in violation
of the 'as if' rule.
Keith Thompson
> Gordon Burditt wrote:
>> jacob navia wrote (and Gordon Burditt rudely snipped the attribution):
But a given GC implementation might cause a C implementation that uses
it to become non-conforming because it causes that implementation to
violate the requirements that the standard *does* define.
For example, it's perfectly legal to take a pointer object, break its
representation down into bytes, and store those bytes separately, then
erase the pointer object's value. You can later reconstitute the
pointer value from the bytes and use it. A typical GC implementation,
such as Boehm's, will detect that there is no pointer currently in
memory that refers to the referenced block of memory, and collect it.
I'm not claiming that that this is an insurmountable problem. You're
free to use an almost-but-not-quite-conforming C implementation if
it's useful to do so, and if the actions that would expose the
nonconformance are rare and easy to avoid. And if GC were
incorporated into a future C standard, the rules would probably be
changed to allow for this kind of thing (by rendering the behavior of
breaking down and reconstituting a pointer like this undefined), at
least in programs for which GC is enabled.
(I do not give permission to quote this article, or any other article
I post to Usenet, without attribution.)
--
Keith Thompson (The_Other_Keith) <ks...@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
I also see nothing wrong with it. However, users need to be aware
that if they write code that depends on GC, they're going to have
problems if they want to use it with an implementation that doesn't
support GC. This is a problem with any extension, no matter how
useful.
(I think it's possible to use the Boehm GC with other compilers. I
don't know how difficult it is.)
jacob navia
> But a given GC implementation might cause a C implementation that uses
> it to become non-conforming because it causes that implementation to
> violate the requirements that the standard *does* define.
>
> For example, it's perfectly legal to take a pointer object, break its
> representation down into bytes, and store those bytes separately, then
> erase the pointer object's value. You can later reconstitute the
> pointer value from the bytes and use it. A typical GC implementation,
> such as Boehm's, will detect that there is no pointer currently in
> memory that refers to the referenced block of memory, and collect it.
>
Then, there is only ONE solution for you and all people like you:
DO NOT USE A GC.
Then, you will happily be able to xor your pointers, store it in files,
whatever.
For the other people that do care about memory management, they can go
on using the GC.
The only reaction from the "regulars" are this kind of very practical
arguments.
Nobody is forbidding anyone to store pointers in files. You can't store
only those that the GC uses. Other pointers can be stored in files
at will, since malloc is still available!
This is typical of their arguments: No substance, just form. There
could be a pointer stored in a file and the standard says at paragraph
blah... blah... blah...
The practical advantages of a GC for a programming language, the pros
and cons... they do not care
Richard Tobin
>> But a given GC implementation might cause a C implementation that uses
>> it to become non-conforming because it causes that implementation to
>> violate the requirements that the standard *does* define.
>Then, there is only ONE solution for you and all people like you:
>
>DO NOT USE A GC.
>
>Then, you will happily be able to xor your pointers, store it in files,
>whatever.
>
>For the other people that do care about memory management, they can go
>on using the GC.
Be reasonable Jacob. You deleted the rest of Keith's article, where
he essentially agrees with you that this problem could be overcome
by changing C's rules when GC is enabled. You could perfectly well
have followed up with more discussion of this without flaming him.
-- Richard
--
:wq
Paul Hsieh
> gaining in popularity and which not:
>
> <quote>
> DDJ: Which languages seem to be losing ground?
>
> PJ: C and C++ are definitely losing ground. There is a simple
> explanation for this. Languages without automated garbage collection are
> getting out of fashion. The chance of running into all kinds of memory
> problems is gradually outweighing the performance penalty you have to
> pay for garbage collection.
> <end quote>
>
> lcc-win has been distributing a GC since 2004.
>
> It really helps.
While I understand what you are doing, it always saddens me that we
are presented with this false dichotomy. Either we have this painful
C interface which is precise and fast, but dangerous and cumbersome or
we have garbage collection which is slow and opaque, but safe and
easy.
GC has the disadvantage that you don't *know* when you are going to
free your memory. In C we have the disadvantage that we don't *know*
what memory we have outstanding/available except by working it out
from the model of our program. C++ helps a little with the RAII
concept, but you can still leak quite easily (and in ways that are
insanely hard to debug.)
If C was merely augmented with total memory consumption statistic
functions and/or heap walking mechanisms and heap checking, all the
main complaints about C's memory management problems would be
immediately addressed. The language itself would then be useful in
discovering problems in code -- even the most complicated structures
would be fairly approachable, because the ability to debug would
always be present.
Alas people don't see it that way. The problem is that people who
remain loyal to C are too quick to defend C's method without even
acknowledging its weaknesses. They are essentially arguing that in
order to support better memory management, you have to go to garbage
collection and give up the rest of the C language while you are at
it. Its just so infuriating to me.
"Why not have GC and malloc/free at the same time" is at least an
acknowledgment that there are other ways of addressing the issue. The
way people obsess over the fact that its impossible to do perfect GC
in C due to some strange pointer obfuscation issue is so telling of
how badly these people miss the point (the chances that you mess up
your memory management in your code is enormously higher than the
chances that you would even consider putting pointer obfuscation in
your program design).
I personally would prefer to go in the direction of improving the
precise memory control model myself. But the ultimate solution (which
may be too hard to implement; I don't know) is to have an augmented
precise memory control interface *in addition* to a directly
compatible GC system (i.e., you would need to support realloc() and
free() on the GC allocated memory in a meaningful way.) A system like
that would offer such an enormous value add; but I don't know that it
could be adopted by the standards committee.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Keith Thompson
jacob, I can only assume that you didn't bother to read what I
actually wrote before you responded.
I did not argue against GC. I pointed out a possible problem that
might be associated with the use of GC, particularly in the context of
conformance to the C standard.
Here's part of what I wrote that you didn't quote in your followup:
| I'm not claiming that that this is an insurmountable problem. You're
| free to use an almost-but-not-quite-conforming C implementation if
| it's useful to do so, and if the actions that would expose the
| nonconformance are rare and easy to avoid. And if GC were
| incorporated into a future C standard, the rules would probably be
| changed to allow for this kind of thing (by rendering the behavior of
| breaking down and reconstituting a pointer like this undefined), at
| least in programs for which GC is enabled.
The C standard was not written with GC in mind. You might want to
argue that it should have been, or that it should be modified so that
it allows for GC, but it's a fact that the current standard doesn't
allow for GC. Because of this, it's not at all surprising that there
might be some corner cases where GC and C standard conformance might
collide.
I pointed out a *minor* issue that *might* cause a problem in some
rare cases. I also mentioned how to avoid that issue. And somehow
you interpreted this as an attack on GC and/or on you personally.
I. Did. Not. Argue. Against. GC.
Please re-read what I actually wrote however many times it takes until
you understand this.
I use languages other than C that depend on built-in garbage
collection, and it's extremely useful. I haven't had an opportunity
to use a C implementation that provides GC, so I can't really comment
on how useful it would be in that context.
Flash Gordon
> user923005 <dco...@connx.com> wrote:
>> On Apr 25, 5:16?am, jacob navia <ja...@nospam.com> wrote:
>>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
>>> gaining in popularity and which not:
>
>> Who's Paul Jansen?
>
>>> <quote>
>>> DDJ: Which languages seem to be losing ground?
>>>
>>> PJ: C and C++ are definitely losing ground. There is a simple
>>> explanation for this. Languages without automated garbage collection are
>>> getting out of fashion. The chance of running into all kinds of memory
>>> problems is gradually outweighing the performance penalty you have to
>>> pay for garbage collection.
>>> <end quote>
>>>
>>> lcc-win has been distributing a GC since 2004.
>>>
>>> It really helps.
>> Is lcc-win outselling Microsoft or Intel's compilers?
>>
>> I guess that most C work is at the embedded level today. I doubt if
>> we will have garbage collectors running in our toasters any time soon.
>
> When people merely say "embedded", I think it confuses the issue.
True and not just for the reasons you give. Sometimes an "embedded"
processor turns out to be a full blown computer running either Linux or
some version of Windows.
> The places where C continues to be used, and will continue to be used, are
> places where the problem is very well defined, and the solution amenable to
> a fixed interface. This happens to be the case for embedded hardware
> products, as well as for many elements of more general purpose computing
> platforms: SQL databases, libraries or applications implementing
<snip>
> And I think that when people characterize the C community as "mostly
> embedded developers", they fall into the trap of excusing or explaining a
> supposed shift; but I don't see a shift in C usage much at all.
There are also applications which are currently written in C where as
bits need to be updated they are replaced with code written in other
languages. Thus in at least some areas (at the very least in some
companies) the number of lines of C code being used is decreasing as an
absolute not just relative amount.
<snip>
> All that's happening is that there are myriad new _types_ of applications,
> many of which C is not well suited for. The old _types_ are still there, and
> usage is growing in absolute terms. There's no need for a bunker mentality.
I agree there is no need for a bunker mentality. Other languages which
are older than me are still alive and well (even if not used as much)
and I'm sure that there will be enough C work around to keep all those
who both want to be C programmers and have the aptitude/attitude to be C
programmers busy for a long time to come.
--
Flash Gordon
Eric Sosman
> Keith Thompson wrote:
>> But a given GC implementation might cause a C implementation that uses
>> it to become non-conforming because it causes that implementation to
>> violate the requirements that the standard *does* define.
>>
>> For example, it's perfectly legal to take a pointer object, break its
>> representation down into bytes, and store those bytes separately, then
>> erase the pointer object's value. You can later reconstitute the
>> pointer value from the bytes and use it. A typical GC implementation,
>> such as Boehm's, will detect that there is no pointer currently in
>> memory that refers to the referenced block of memory, and collect it.
>>
>
> Then, there is only ONE solution for you and all people like you:
>
> DO NOT USE A GC.
Um, er, isn't that what he said in the part you snipped?
It went like this (emphasis mine):
:> [...] And if GC were
:> incorporated into a future C standard, the rules would probably be
:> changed to allow for this kind of thing (by rendering the behavior of
:> breaking down and reconstituting a pointer like this undefined), at
^^
:> least in programs for which GC is enabled.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> For the other people that do care about memory management, they can go
> on using the GC.
The people who "care about memory management" don't need GC:
They manage their memory themselves *because* they care about it.
GC is for the people who choose not to manage their memory; just
dropping memory on the floor and letting GC sweep it up is prima-
facie evidence that the programmer does *not* "care about memory
management" and chooses to leave it to someone else.
> The practical advantages of a GC for a programming language, the pros
> and cons... they do not care
GC has practical advantages for some programming languages;
nobody disputes that. I cannot imagine LISP without it, nor
SNOBOL, nor Java, and others I've never used. But the fact that
languages X,Y,Z benefit from garbage collection does not imply
that all languages would, nor even that any particular other
language would. The same could be said for pretty much any
other language feature you care to name: FORTRAN benefits from
built-in complex numbers, but does that mean awk needs them?
Perl benefits from built-in regular expression machinery; does
that mean assembly language should have it, too?
In my opinion, it is not helpful to C to try to lard it up
with every cute feature of every programming environment every
enthusiast ever sighed over.
jacob navia
> On Apr 25, 5:16 am, jacob navia <ja...@nospam.com> wrote:
>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
>> gaining in popularity and which not:
>>
>> <quote>
>> DDJ: Which languages seem to be losing ground?
>>
>> PJ: C and C++ are definitely losing ground. There is a simple
>> explanation for this. Languages without automated garbage collection are
>> getting out of fashion. The chance of running into all kinds of memory
>> problems is gradually outweighing the performance penalty you have to
>> pay for garbage collection.
>> <end quote>
>>
>> lcc-win has been distributing a GC since 2004.
>>
>> It really helps.
>
> While I understand what you are doing, it always saddens me that we
> are presented with this false dichotomy. Either we have this painful
> C interface which is precise and fast, but dangerous and cumbersome or
> we have garbage collection which is slow and opaque, but safe and
> easy.
>
Surely my intention wasn't to make an alternative out of GC or
not GC! There are many other possibilities.
> GC has the disadvantage that you don't *know* when you are going to
> free your memory.
I see it precisely as an advantage. I do not know and I do not want
to know it precisely. I want that the machine keeps track of it and
not me. In *some* cases you want to know when you free it, for instance
if you have allocated a huge block and want to release it immediately to
avoid a GC. In that cases you call GC_free() that releases the memory
block immediately.
In C we have the disadvantage that we don't *know*
> what memory we have outstanding/available except by working it out
> from the model of our program. C++ helps a little with the RAII
> concept, but you can still leak quite easily (and in ways that are
> insanely hard to debug.)
>
Like all C++ :-)
> If C was merely augmented with total memory consumption statistic
> functions and/or heap walking mechanisms and heap checking, all the
> main complaints about C's memory management problems would be
> immediately addressed. The language itself would then be useful in
> discovering problems in code -- even the most complicated structures
> would be fairly approachable, because the ability to debug would
> always be present.
>
C programmers do not need debuggers and can debug programs by phone
without the source.
Dixit...
This attitude about debugging (debugging is only for stupid people that
have bugs. I do not have any bugs since I am the best programmer in the
world) permeates all the philosophy of the language, and memory
management is no exception.
No care is given to the debugging features of malloc/free at all.
> Alas people don't see it that way. The problem is that people who
> remain loyal to C are too quick to defend C's method without even
> acknowledging its weaknesses.
My language right or wrong!
> They are essentially arguing that in
> order to support better memory management, you have to go to garbage
> collection and give up the rest of the C language while you are at
> it. Its just so infuriating to me.
>
GC is one solution. Your proposal would be another. I do not see why you
think it is an either/or thing.
> "Why not have GC and malloc/free at the same time" is at least an
> acknowledgment that there are other ways of addressing the issue.
The malloc/free system is still there of course!
> I personally would prefer to go in the direction of improving the
> precise memory control model myself. But the ultimate solution (which
> may be too hard to implement; I don't know) is to have an augmented
> precise memory control interface *in addition* to a directly
> compatible GC system (i.e., you would need to support realloc() and
> free() on the GC allocated memory in a meaningful way.) A system like
> that would offer such an enormous value add; but I don't know that it
> could be adopted by the standards committee.
>
I can't implement that. I do not have the time. If there was an effort
where I could collaborate I would, but I can't do it alone.
> --
> Paul Hsieh
> http://www.pobox.com/~qed/
> http://bstring.sf.net/
jacob navia
>
> I did not argue against GC. I pointed out a possible problem that
> might be associated with the use of GC, particularly in the context of
> conformance to the C standard.
>
Please, that stuff appears every time I mention the GC here.
"I *could* store pointers in disk and read it later, so the GC
is not conforming"
You know that this has no practical significance at all. Since a
conforming program that stores pointers in the disk is using
malloc/free and that system is still available, those programs
would CONTINUE TO RUN!
The only case where the program would NOT run is if they use the GC
allocated pointers and put them in the disk!
But this is the same as saying that
I stored the socket descriptor in the disk and then, next day, when I
turned on the machine the network connection would not work...
Don't you think that it would be much more substantial to address the
issues that the GC poses in a substantive way?
Or the issues about the debugging support that Paul Hsie proposes?
That would be more interesting that the ethernal "GC-and-storing
pointers in the disk" discussion!
cr88192
"Yunzhong" <gaoyu...@gmail.com> wrote in message
news:4e2457ef-e23e-41a5...@b64g2000hsa.googlegroups.com...
I wasn't saying it would die out "soon". what I wrote about could easily
take 10 or 15 years to play out at the current rates...
but, my speculation is like this:
C will fall out of favor for mainstream app development (it already largely
has), but will likely retain a stronghold in low-level systems, namely:
embedded systems, OS-kernels, drivers, domain-specific languages (ok, likely
C-variants), libraries, VMs, ...
meanwhile, C++ is currently at its high-point, and I will guess will start
to decline at a faster rate than C (in 15 years, it may have largely fallen
into disuse). a partial reason for this being a "high cost of maintainence"
(for both code and implementations, the language less likely to overtake C's
strongholds, it falls into decline).
Java is likely to overtake C++, and for a while become the dominant language
for app development.
C# is likely to grow at a faster rate than Java, at some point (say, 5-10
years) overtaking both, however. in this time, to make a guess, .NET will
either be abandoned or heavily mutated (for example, .GNU, which in time may
likely mutate in a divergent path).
at the current rates, in this time period, Windows will also fall behind,
with most likely the mainstream OS being Linux (thus, C# would become the
dominant language, on Linux...).
however, this is predicated on the language and apps being able to
effectively make the transition (the fall of Windows majorly hurting, but
not likely killing, the language).
and in the course of all this, new languages emerge that further begin to
overtake the current generation (IMO, there will never be an "ultimate
language", only new ones, most changing what they will, but otherwise being
very conservative).
the mainstream language in 20 years could very well by a hybrid of C#,
JavaScript, and features from many other languages...
by this time, I also expect notable mutations in terms of kernel
architecture and filesystems, us likely facing the demise of both processes
and heirarchical filesystems... Linux either facing replacement, or being
internally restructured into something almost unrecognizable...
and so on...
as noted, this is mostly all just speculation here...
user923005
> "Yunzhong" <gaoyunzh...@gmail.com> wrote in message
Looking at the past is always easy.
Prophecy proves more difficult.
Bartc
"Eric Sosman" <Eric....@sun.com> wrote in message
news:1209149152.181452@news1nwk...
> user923005 wrote:
>> I guess that most C work is at the embedded level today. I doubt if
>> we will have garbage collectors running in our toasters any time soon.
>
> That's why the toast crumbs keep accumulating at the bottom.
There might be a little tray that you can slide out to remove the crumbs
easily.
--
Bart
Bartc
> gaining in popularity and which not:
>
> <quote>
> DDJ: Which languages seem to be losing ground?
>
> PJ: C and C++ are definitely losing ground. There is a simple explanation
> for this. Languages without automated garbage collection are getting out
> of fashion. The chance of running into all kinds of memory problems is
> gradually outweighing the performance penalty you have to pay for garbage
> collection.
> <end quote>
>
> lcc-win has been distributing a GC since 2004.
I've little idea about GC or how it works (not about strategies and things
but how it knows what goes on in the program).
What happens in this code fragment:
void fn(void) {
int *p = malloc(1236);
}
when p goes out of scope? (Presumably some replacement for malloc() is
used.)
What about a linked list when it's no longer needed? How does GC know that,
do you tell it? And it knows where all the pointers in each node are. I can
think of a dozen ways to confuse a GC so it all sounds like magic to me, if
it works.
--
Bart
Gordon Burditt
>
>"I *could* store pointers in disk and read it later, so the GC
>is not conforming"
>
>You know that this has no practical significance at all. Since a
I asked for what rules the GC breaks. Anyone using your GC ought
to know this. The response seems to be a complete denial that it's
an issue at all.
Some of the consequences are not of much practical consequence (like
storing pointers on disk). Some of the consequences might be
significant (like not being allowed to use signal handlers AT ALL,
or not being allowed to use dynamically-allocated memory (I didn't
say allocate or free, which you can't do anyway, I said *use*).
Does your implementation have this problem? I don't know. I'd be
VERY concerned if 2+2 occasionally came out 5.
>conforming program that stores pointers in the disk is using
>malloc/free and that system is still available, those programs
>would CONTINUE TO RUN!
Not if GC freed what the pointer points at, and it got re-used for
something else.
>The only case where the program would NOT run is if they use the GC
>allocated pointers and put them in the disk!
Which is perfectly legitimate. I even wrote a program that did
this (without GC) because a giant table wouldn't fit in memory but
the NAMES of things would. So pieces of the table got "swapped"
(CP/M didn't have real swapping, so it was done manually to a file)
to (floppy) disk, and the name strings stayed put, and the pointers
to the names existed mostly in the temporary file.
>But this is the same as saying that
>
>I stored the socket descriptor in the disk and then, next day, when I
>turned on the machine the network connection would not work...
No, it's not the same. C makes no guarantees about sockets at all,
but it does guarantee that THE SAME INSTANCE OF A RUNNING PROGRAM
may store and retrieve pointers and expect them to be valid.
I believe POSIX also allows you to store socket descripter numbers on disk
and then retrieve them IN THE SAME PROCESS (and assuming it's still open).
>Don't you think that it would be much more substantial to address the
>issues that the GC poses in a substantive way?
I don't know what else your implementation breaks, and it's not at
all obvious. Does it break all use of signal handlers? Does it
break all use (not malloc and free, *use*) of dynamically allocated
memory in signal handlers? Does it break all use of data pointers
in signal handlers?
>Or the issues about the debugging support that Paul Hsie proposes?
The C standard doesn't require debugging support.
>That would be more interesting that the ethernal "GC-and-storing
>pointers in the disk" discussion!
I recommend you just admit that GC breaks if you store and later retrieve
the only references to dynamically allocated memory. It's not a practical
problem as very, very few programs do this. If GC is optional (as in
a command-line flag to the compiler) it's very easy: document the kinds
of things programs CAN'T do with GC, and say that these programs should
turn GC off.
Now: WHAT *ELSE* DOES IT BREAK?
lawrenc...@siemens.com
>
> If C was merely augmented with total memory consumption statistic
> functions and/or heap walking mechanisms and heap checking, all the
> main complaints about C's memory management problems would be
> immediately addressed.
And a number of very fast and very useful allocations methodologies
would no longer be valid.
-Larry Jones
I hate it when they look at me that way. -- Calvin
Chris Torek
Bartc <b...@freeuk.com> wrote:
>I've little idea about GC or how it works ...
>What happens when [the only pointer to a successful malloc() result]
>goes out of scope?
>What about a linked list when it's no longer needed? How does GC know that,
>do you tell it? And it knows where all the pointers in each node are. ...
There are a bunch of different ways to implement garbage collectors,
with different tradeoffs. To make one that works for all cases,
though, including circularly-linked data structures, one ultimately
has to compute a sort of "reachability graph".
Suppose, for instance, we have a table somewhere of "all allocated
blocks" (whether this is a list of malloc()s made into an actual
table or tree or whatever, or a set of pages for a page-based
collector, just picture it mentally as a regular old table, as if
it were written out on a big sheet of paper). The table has whatever
entries it needs to keep track of addresses and sizes -- if it is
a malloc() table, that might well be all it needs -- except that
it has a single extra bit, which we can call "referenced".
To do a full GC, we run through the table and clear all the
"referenced" bits. Then, we use some sort of System Magic to find
all "root pointers". In C, this could be "every address register,
plus every valid address" (on a machine that has those), or "those
parts used by the C compiler, ignoring things that might be used
by other languages" (this will probably speed up the GC -- if we
know the C compiler never stores a pointer in registers 5, 6, and
7, we can ignore them; if we know the C compiler never stores
pointers in "text segments" we can skip those, and so on). In
non-C languages, it may be much easier to find all root pointers
(for instance a Lisp system may have just one or a few such values).
Then we hit the really tricky part: for each root pointer, if it
points into some entry in the table, we set the "referenced" bit
to mark that entry as used, and -- recursively -- check the entire
memory area described by that table entry for more pointers. (If
the referenced bit is already set, we assume that the memory area
has been scanned earlier, and skip this scan. This prevents infinite
recursion, if a malloc()ed block contains pointers to itself.)
When we have finished marking each entry according to each root
pointer and all "reachable pointers" found via that pointer, we
make one final pass through the table, freeing those table entries
whose bits are still clear.
In other words, in code form, and making even more assumptions
(that there is just one "kind" of pointer -- if there are three
kinds, VALID_PTR() and/or find_entry_containing() become complicated):
void __scan(TABLE_ENTRY *);
TABLE_ENTRY *__find_entry_containing(POINTER_TYPE);
__GC() {
TABLE_ENTRY *e;
POINTER_TYPE p;
for (e in all table entries)
e->ref = 0;
for (p in all possible root pointers)
if (VALID_PTR(p) && (e = __find_entry_containing(p)) != NULL)
__scan(e);
for (e in all table entries)
if (!e->ref)
__internal_free(e);
}
void __scan(TABLE_ENTRY *e) {
TABLE_ENTRY *inner;
if (e->ref)
return; /* nothing to do */
e->ref = 1;
for (p taking on all possible valid pointers based on e)
if ((inner = __find_entry_containing(p)) != NULL)
__scan(inner);
}
As you might imagine, all of these are pretty tricky to implement
correctly, and the scanning can take a very long time. These are
why there are so many kinds of GC systems.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
Paul Hsieh
> Paul Hsieh <websn...@gmail.com> wrote:
> > If C was merely augmented with total memory consumption statistic
> > functions and/or heap walking mechanisms and heap checking, all the
> > main complaints about C's memory management problems would be
> > immediately addressed.
>
> And a number of very fast and very useful allocations methodologies
> would no longer be valid.
Its easy to talk isn't it? If you can perform free() and realloc()
correctly that means you, in some sense *know* what those memory
contents are. All the credible strategies I have looked at (bitmaps,
buddy systems, and just the header/footer linkage systems), one way or
another can support *all* the useful relevant extensions with minimal
performance impact.
People are voting with their feet with this programming language and
its because of false dichotomies like this. If there's some marginal
crazy system that can't support this, its not going to be updated to
the latest standard anyway. Its like you guys didn't take away any
lesson from the lack of C99 adoption.
Richard Heathfield
<snip>
> C programmers do not need debuggers and can debug programs by phone
> without the source.
>
> Dixit...
>
> This attitude about debugging (debugging is only for stupid people that
> have bugs. I do not have any bugs since I am the best programmer in the
> world) permeates all the philosophy of the language, and memory
> management is no exception.
It is plain from the above that you are guilty of misrepresentation, either
maliciously or accidentally. If it's malicious, that makes you a troll. If
it's accidental, it makes you an idiot (because it has already been
explained to you several times *why* it is a misrepresentation).
If you want garbage collection, you know where to find it. I can't see
anything that stops you from using it if you want to. After all, you never
use platforms where it isn't available, right?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
cr88192
"user923005" <dco...@connx.com> wrote in message
news:e76d9c78-ad7c-44d8...@l64g2000hse.googlegroups.com...
>On Apr 25, 3:34 pm, "cr88192" <cr88...@NOSPAM.hotmail.com> wrote:
>> "Yunzhong" <gaoyunzh...@gmail.com> wrote in message
>>
<snip>
>>
>> and so on...
>>
>> as noted, this is mostly all just speculation here...
>
> Looking at the past is always easy.
> Prophecy proves more difficult.
>
yes, however, IME it is not always so difficult...
my approach consists of taking the current observed trends, and "running
them forwards".
the reason I can try to predict so far ahead, is given the incredibly slow
rate of change WRT programming languages.
now, my claim here is not accuracy, only a vague guess...
however, even vague guesses can be worthwhile...
something different could happen, so then one has to consider, how likely is
it that it will happen this way, and how likely it is that it will happen
some other way...
my understanding of the trends, is because I have lived through many of the
changes, and have watched them progress at the terribly slow rate at which
they are going, and so, can make a guess as to what will happen within a
related timeframe.
I think, the next 10 years are not too hard to guess (ignoring any
catastrophic events or revolutionary changes, but these are rare enough to
be ignored).
moving much outside this, say, 15 or 20 years, requires a good deal more
speculation.
the reason for a decline in windows and rise of linux would be due to the
current decline in windows and current rise in linux. I had just assumed
that these continue at the current rates.
the reason for a decline in the process model would be because of the rise
of VM-like developments (however, it is very possible that processes may
remain as a vestigial feature, and thus not go away).
as for filesystems, the prediction is that they move from being pure
heirarchies, to being annotated with so much metadata that they are, in
effect, based on the network-model, rather than heirarchical.
other guesses:
I can also claim, in a similar line of thought that, most likely, in 10
years, x86-64 will most likely be the dominant architecture.
estimating from current curves, computers will likely have around 256GB RAM,
and HDs will be around 125TB...
the model doesn't hold up so well WRT processor power, a crude guess is that
there will be around 64 cores, processing power being somewhere between 1.1
and 1.5 TFLOP (assuming only a gradual increase in terms of per-core power
and that the per-core complexity will go up a little faster than the
transistor density). an uncertainty here is in the scope and nature of
future vector extensions, so my guess is likely to be conservative...
3D lithography and Stack-chips, allong with reaching a maximal transistor
density, are other factors that could throw predictions (currently based
simply on mental curve approximation).
user923005
> "user923005" <dcor...@connx.com> wrote in message
>
> news:e76d9c78-ad7c-44d8...@l64g2000hse.googlegroups.com...
>
> >On Apr 25, 3:34 pm, "cr88192" <cr88...@NOSPAM.hotmail.com> wrote:
> >> "Yunzhong" <gaoyunzh...@gmail.com> wrote in message
>
> <snip>
>
>
>
> >> and so on...
>
> >> as noted, this is mostly all just speculation here...
>
> > Looking at the past is always easy.
> > Prophecy proves more difficult.
>
> yes, however, IME it is not always so difficult...
>
> my approach consists of taking the current observed trends, and "running
> them forwards".
>
> the reason I can try to predict so far ahead, is given the incredibly slow
> rate of change WRT programming languages.
Exactly. COBOL and Fortran are still going strong.
> now, my claim here is not accuracy, only a vague guess...
> however, even vague guesses can be worthwhile...
That, and $3.75 will get you a cup of coffee.
> something different could happen, so then one has to consider, how likely is
> it that it will happen this way, and how likely it is that it will happen
> some other way...
>
> my understanding of the trends, is because I have lived through many of the
> changes, and have watched them progress at the terribly slow rate at which
> they are going, and so, can make a guess as to what will happen within a
> related timeframe.
>
> I think, the next 10 years are not too hard to guess (ignoring any
> catastrophic events or revolutionary changes, but these are rare enough to
> be ignored).
I think that the next ten years will be an even bigger surprise than
the previous ten years, and the surprises will accelerate. Since
total knowledge doubles every 5 years now, and the trend is going
exponential-exponential, I think that projecting what will be is much
harder than you think.
> moving much outside this, say, 15 or 20 years, requires a good deal more
> speculation.
I think that 6 months from now is difficult, even for stock prices,
much less industry trends. We can mathematically project these things
but you will see that the prediction and confidence intervals bell out
in an absurd manner after the last data point.
> the reason for a decline in windows and rise of linux would be due to the
> current decline in windows and current rise in linux. I had just assumed
> that these continue at the current rates.
I guess that 15 years from now Windows will still dominate, unless the
Mac takes over or Linux does really well. Linux is not a desktop
force, but it is making server inroads.
> the reason for a decline in the process model would be because of the rise
> of VM-like developments (however, it is very possible that processes may
> remain as a vestigial feature, and thus not go away).
VM developmments are nice, but we lose horsepower. I'm not at all
sure it is the right model for computation.
> as for filesystems, the prediction is that they move from being pure
> heirarchies, to being annotated with so much metadata that they are, in
> effect, based on the network-model, rather than heirarchical.
I think that file systems should be database systems, like the AS/400
and even OpenVMS have.
> other guesses:
>
> I can also claim, in a similar line of thought that, most likely, in 10
> years, x86-64 will most likely be the dominant architecture.
I guess five years, but maybe not. We are going 64 bit here now, both
with machines and OS, but it's still a few weeks off. However, I
guess that our office is atypical.
> estimating from current curves, computers will likely have around 256GB RAM,
> and HDs will be around 125TB...
256G Ram is way too low for 10 years from now. My guess would be 1 TB
give or take a factor of 2.
I suspect we won't be using platter based hard drive technology ten
years from now. I know of some alternate technologies that will store
1 TB on one square cm and so something like that will take over once
the disk drive manufacturers have depreciated their current capital.
> the model doesn't hold up so well WRT processor power, a crude guess is that
> there will be around 64 cores, processing power being somewhere between 1.1
> and 1.5 TFLOP (assuming only a gradual increase in terms of per-core power
> and that the per-core complexity will go up a little faster than the
> transistor density). an uncertainty here is in the scope and nature of
> future vector extensions, so my guess is likely to be conservative...
I don't know if core count will be the thing that pushes technology or
some completely new idea.
It went like this before:
Mechanical switch
Relay
Vacuum tube
Transistor
IC
VLSI
> 3D lithography and Stack-chips, allong with reaching a maximal transistor
> density, are other factors that could throw predictions (currently based
> simply on mental curve approximation).
I guess something new will come along right about the time that
silicon can no longer keep up. It always has before.
We get ourselves into trouble when we try to predict the future. Look
at the economic analysis by Marx and Engels. It was very good. But
their predictions on what the future held were not so good.
I think that we have a hard time knowing for sure about tomorrow.
Next week is a stretch. Next year is a guess. Five years is
speculation. Ten years is fantasy. Twenty years is just being silly.
IMO-YMMV
Now, is there some C content in here somewhere? Oh, right -- C is
going to lose force. I predict:
1. C will lose force.
OR
2. C will gain force.
OR
3. C will stay the same.
That's trichotomy for you. And I can guarantee that I am right about
it.
Keith Thompson
> Keith Thompson wrote:
>> I did not argue against GC. I pointed out a possible problem that
>> might be associated with the use of GC, particularly in the context of
>> conformance to the C standard.
>
> Please, that stuff appears every time I mention the GC here.
I posted it in direct response to a discussion about whether GC breaks
C standard conformance.
> "I *could* store pointers in disk and read it later, so the GC
> is not conforming"
Storing pointers on disk is not the only case I mentioned.
I can easily imagine a program that encrypts some in-memory data
structure and decrypts it later, to protect against snooping by other
users on the machine. That data structure could easily include the
only pointers to some chunk of memory outside the encrypted region.
> You know that this has no practical significance at all. Since a
> conforming program that stores pointers in the disk is using
> malloc/free and that system is still available, those programs
> would CONTINUE TO RUN!
>
> The only case where the program would NOT run is if they use the GC
> allocated pointers and put them in the disk!
It's something you have to think about when deciding to use GC.
That's all.
Now that you mention it, I think the point about malloc vs. gc_malloc
(sp?) was brought up in this context before. If memory allocated by
malloc isn't garbage-collected, then there may not be a conformance
issue; the behavior of gc_malloc and of memory allocated to it is
implementation-defined, and the standard doesn't impose the same
requirements on it as it does on malloc-created pointers and what they
point to. So I may have been mistaken. I've participated in a lot of
discussions here; I do occasionally forget some of the details.
Even so, a programmer using GC still has to be aware that there are
some (admittedly exotic) things that he can't do with the resulting
pointers.
And even if I made a minor error, that is no excuse for your
insufferable rudeness. If you're bored by my bringing it up in
response to somebody else's question, then DON'T ANSWER. I wasn't
talking to you anyway.
[snip]
Ian Collins
>
> I can also claim, in a similar line of thought that, most likely, in 10
> years, x86-64 will most likely be the dominant architecture.
>
server market. You'd be hard pushed to find a new 32 bit machine these
days.
--
Ian Collins.
rio
news:fusi33$e0n$1...@aioe.org...
> Re: Garbage collection
the garbage collection is the wrong direction
it is better a malloc-free system that allow check on boundary [edge]
and check on memory leak too, because it is easy that find errors.
the ideal language is a language that make to sound the bells
(write it down in a queue log file)
when there is some error
Buon Giorno
r_io
cr88192
> On Apr 25, 8:41 pm, "cr88192" <cr88...@NOSPAM.hotmail.com> wrote:
>
>> the reason I can try to predict so far ahead, is given the incredibly
>> slow
>> rate of change WRT programming languages.
>
> Exactly. COBOL and Fortran are still going strong.
>
yes, but are still less dominant than they were...
assembler is still going strong as well FWIW...
>> now, my claim here is not accuracy, only a vague guess...
>> however, even vague guesses can be worthwhile...
>
> That, and $3.75 will get you a cup of coffee.
>
depends, I have not really been to cafes.
I can get steel cans of coffee 2 for 1$...
I think it is 0.75$ for coffee in a plastic bottle.
all this is at a nearby convinience store...
>>
>> I think, the next 10 years are not too hard to guess (ignoring any
>> catastrophic events or revolutionary changes, but these are rare enough
>> to
>> be ignored).
>
> I think that the next ten years will be an even bigger surprise than
> the previous ten years, and the surprises will accelerate. Since
> total knowledge doubles every 5 years now, and the trend is going
> exponential-exponential, I think that projecting what will be is much
> harder than you think.
>
yeah.
well, one can wait and see I guess...
>> moving much outside this, say, 15 or 20 years, requires a good deal more
>> speculation.
>
> I think that 6 months from now is difficult, even for stock prices,
> much less industry trends. We can mathematically project these things
> but you will see that the prediction and confidence intervals bell out
> in an absurd manner after the last data point.
>
stocks are likely to be much harder I think, considering that they vary
chaotically and have strong feedback properties, rather than gradually over
a long period of time...
my guess is that predictions get far worse the further one moves into the
future, which is why I can speculate 10 years, but I don't really make any
solid claims for 20 years.
in the reverse direction, I can assert with pretty good confidence that
within 6 months or 1 year that the programming-language landscape will be
much the same as it is right now.
>> the reason for a decline in windows and rise of linux would be due to the
>> current decline in windows and current rise in linux. I had just assumed
>> that these continue at the current rates.
>
> I guess that 15 years from now Windows will still dominate, unless the
> Mac takes over or Linux does really well. Linux is not a desktop
> force, but it is making server inroads.
>
Windows dominance is possible, but unless recent trends change, I don't
expect it to last.
I also personally doubt that Mac is going to regain dominance (though it
can't really be ruled out either).
the great problem with Mac is that there is not many good reasons for people
TO use it, so it seems most likely that they will not.
at this point, Linux is not a desktop force (or even a very good desktop
OS), however, the Linux driver support situation is steadily improving, and
opensource apps are gaining a strong footing vs commercial apps (for
example, at my college they use OpenOffice rather than MS Office, ...).
as such, it may be not too long before Windows and Linux are "comprable" in
many respects, and if MS throws out much more total crap (like they have
done with Vista, ...), they may just end up convincing a lot more people to
make the switch...
>> the reason for a decline in the process model would be because of the
>> rise
>> of VM-like developments (however, it is very possible that processes may
>> remain as a vestigial feature, and thus not go away).
>
> VM developmments are nice, but we lose horsepower. I'm not at all
> sure it is the right model for computation.
>
I agree, technically.
VMs are not necessarily the "best" idea, but they may well continue to gain
sway over more conventional static-compilation approaches in many cases.
however, this was more in my longer-term speculation (I still expect static
compilation will be dominant in 10 years, but VMs and hybrid approaches may
become common as well).
I expect there will be a lot more hybrid apps/VMs (usually, with part of the
app being statically compiled, and part of the app running in a VM), than
either purely statically compiled, or purely VM-based apps.
however, I don't really know in which direction this will go (or which exact
form things will take).
>> as for filesystems, the prediction is that they move from being pure
>> heirarchies, to being annotated with so much metadata that they are, in
>> effect, based on the network-model, rather than heirarchical.
>
> I think that file systems should be database systems, like the AS/400
> and even OpenVMS have.
>
I doubt, however, that something like the AS/400 or OpenVMS will gain sway,
more likely, it will be conventional filesystems with some huge amount of
crufty metadata tacked on, probably with features like union-directories,
... fouling up what had formerly been a clean heirarchical filesystem.
some of this had already been added to Linux, and may change primarily in
the way of becoming "standard" filesystem features, in much the same way as
long filenames, unicode filenames, and symbolic links...
notice on a modern Linux distro just how long the list of mounts can end up
being...
>> other guesses:
>>
>> I can also claim, in a similar line of thought that, most likely, in 10
>> years, x86-64 will most likely be the dominant architecture.
>
> I guess five years, but maybe not. We are going 64 bit here now, both
> with machines and OS, but it's still a few weeks off. However, I
> guess that our office is atypical.
>
possibly, or at least this will be when the "bulk" transition is
completed...
it has been about 12 years since 32 bit OSs have been the norm, but we still
have some 16 bit apps floating around...
in 10 years, likely x86-64 will still be dominant, but maybe there will be a
competitor by this point or a transition to a new major replacement...
>> estimating from current curves, computers will likely have around 256GB
>> RAM,
>> and HDs will be around 125TB...
>
> 256G Ram is way too low for 10 years from now. My guess would be 1 TB
> give or take a factor of 2.
>
it was a linear guess based on vague memory.
in 1998, a new desktop came with like 64MB RAM and a P2, now a desktop can
come with 4GB.
so, my estimate was linear...
> I suspect we won't be using platter based hard drive technology ten
> years from now. I know of some alternate technologies that will store
> 1 TB on one square cm and so something like that will take over once
> the disk drive manufacturers have depreciated their current capital.
yeah. I was ignoring the technology, again, guessing based on linear
estimation from past trends.
as for current magnetic recording, AFAIK they are using tricks like vertical
polarization and have multi-layer magnetic recording, ...
I was just making a crude guess that they continue increasing the density on
magnetic platters much as they have done for the past few decades. nevermind
that by the time magnetic platters could pull off densities like this,
probably the underlying recording will work very different.
for example, rather than polarizing specific points in the medium, the
recording will consist of a good number of likely overlapping magnetic
fields, and likely be geometric rather than linear (for example, each point
represents a 3D vector or unit-quaternion value rather than a scalar). the
encoding and decoding electronics then go about converting chunks of data
into masses of overlapping geometric waveforms (data being encoded in terms
of both the orientation and the nature of the paths taken around the surface
of a 4D unit sphere...).
note that a single head would be used, but would likely consist of 4+
directional magnetic sensors (a tripod and a vertical sensor), the
orientation measured via triangulation or similar (note that a transform
would be needed, since the sensor axes would be non-orthogonal, ...).
additional sensors could allow a vertical component to be added as well
(basically, we could then have 6 axes per track, XYZW VL, where XYZW form a
Quaternion, V represents a limited-range vertical component, possibly
allowing encoding arcs or spirals, or stacking spheres, or similar, and L
represents the linear position along the track).
so, I suspect thay, yes, we can squeeze a little more density out of these
here magnetic platters (currently, we only exploit 2 magnetic axes, or 3 in
some newer drives...).
>> the model doesn't hold up so well WRT processor power, a crude guess is
>> that
>> there will be around 64 cores, processing power being somewhere between
>> 1.1
>> and 1.5 TFLOP (assuming only a gradual increase in terms of per-core
>> power
>> and that the per-core complexity will go up a little faster than the
>> transistor density). an uncertainty here is in the scope and nature of
>> future vector extensions, so my guess is likely to be conservative...
>
> I don't know if core count will be the thing that pushes technology or
> some completely new idea.
> It went like this before:
> Mechanical switch
> Relay
> Vacuum tube
> Transistor
> IC
> VLSI
I don't really know here...
>> 3D lithography and Stack-chips, allong with reaching a maximal transistor
>> density, are other factors that could throw predictions (currently based
>> simply on mental curve approximation).
>
> I guess something new will come along right about the time that
> silicon can no longer keep up. It always has before.
>
yeah.
> We get ourselves into trouble when we try to predict the future. Look
> at the economic analysis by Marx and Engels. It was very good. But
> their predictions on what the future held were not so good.
>
IMO, they screwed up really hard in that they analyzed everything, and then
set out to rework everything in their own image. necessarily that does not
go over as well...
personally I have a lot more respect for Nietzsche...
> I think that we have a hard time knowing for sure about tomorrow.
> Next week is a stretch. Next year is a guess. Five years is
> speculation. Ten years is fantasy. Twenty years is just being silly.
>
yes, but even for being speculative, there can be at least some merit...
of course, note that I personally tend to use bottom-up planning, rather
than top-down planning, so my approaches tend to be a lot more tolerant to
prediction errors (in my case, I often assume that predictions are likely to
be incorrect anyways, so it is always good to keep a good fallback handy in
case things work out differently than expected...).
> IMO-YMMV
>
> Now, is there some C content in here somewhere? Oh, right -- C is
> going to lose force. I predict:
> 1. C will lose force.
> OR
> 2. C will gain force.
> OR
> 3. C will stay the same.
>
> That's trichotomy for you. And I can guarantee that I am right about
> it.
2 is unlikely (it is already near the top), as is 3 (what was ideal when C
was going strong are becomming gradually less the case).
assuming 1, we can then guess from the available most-likely options.
Friedrich Dominicus
>
> What happens in this code fragment:
>
> void fn(void) {
> int *p = malloc(1236);
> }
>
> when p goes out of scope? (Presumably some replacement for malloc() is
> used.)
I think this one is a reayll simply example. And I would be very
suprised if any GC would fail on this simple thing. As you can see p
can never be reached after leaving the function. So it's clear that
it's "free" to be collected.
The point with GC is that you better have some language support. C
does not support you with anything. As Ken has pointed out you can
take apart a pointer and reconstruct it (hopefulyl ones knows how to
do that) But I can not see that in simple cases this can be a
problem, it if was then the Boehm Weisser GC could not work at
all. But it works quite well.
So I'd argue as long as you do not play "dirty" tricks with your
Pointers you can assume that the GC works. Of course if anyone beeing
against GC wouldn't mind to post a very simply example on where this
failed I realyl would be curious to learn that.
I for my part just can see that the Boehm Weisser GC is used in very
many different packages and it seems that works flawless. If I'd the
chance of using it I do not hesitate to do so.
For me this is one part in langauge development where the "machine"
can do better than me, and I'm very happy to give that task to it.
>
> What about a linked list when it's no longer needed? How does GC know that,
> do you tell it? And it knows where all the pointers in each node are. I can
> think of a dozen ways to confuse a GC so it all sounds like magic to me, if
> it works.
Well if you keep track of every allocation, then you know where your
pointers are, after that it's "just" travesing them all if you find
some are not any longer reachable it's safe to throw them away. Of
course bugs can and will happen, but I'd argue after more than 60
years of GCs in diverse languages the big bummers have gone. I for my
part would trust any application "controlled by GC" more than any a
bit larger new C program doing that all by "hand".
But the nice thing is that you have the choice (well sometimes you
don't), but if I think of a well known OS and it's many "memory
allocation schemes" I start to shiver. It's a miracle that it
works, and it's IMHO a big achievement of the people involved in
programming to get that into that state... Howerver I doubt
anyone knows how much time they were hunting down resource problems,
and how much time and effort they spend on developging tools for
helping them finding bugs. At least it seems a not so small industry has
lived well (and still lives) on hunting down such resouce
problems. And I can't remember having it seen in another context as C
and derivates or Pascal and derivates, language without initial GC.
Regards
Friedrich
--
Please remove just-for-news- to reply via e-mail.
cr88192
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:67fp6tF...@mid.individual.net...
yes, and it will probably remain so for a while.
in not too long probably the software will start to catch up...
> --
> Ian Collins.
Ian Collins
--
Ian Collins.
Herbert Rosenau
wrote:
>
> Surely my intention wasn't to make an alternative out of GC or
> not GC! There are many other possibilities.
There is absolutely no cause to trust a compiler whoes author is
unable to understund the standard and likes to ignore it anyway.
So jacob navia <ja...@nospam.com> proves himsel again and again as
fool noit only by spamming but by ignoring the standard too.
--
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!
Herbert Rosenau
wrote:
> lcc-win has been distributing a GC since 2004.
Fool, stop spamming for your properitary product that has nothing to
do with the topic of this group!
jacob navia <ja...@nospam.com> ignores constantly the topic of clc to
spam for his faulty compiler of something that has nothing to do with
the topic of this group. Spammer go away!
jacob navia <ja...@nospam.com> knows nothing about the standard as he
proves constantly with his spam - or where in the standard is GC
mentioned? Giving something away for free does not allow to spam for
it anyway!
Richard
For new machines maybe (maybe!), but the fact is that people do not
upgrade that often anymore - the curve has flattened IMO.
vipp...@gmail.com
> >lcc-win has been distributing a GC since 2004.
>
>
> In what ways does that implementation violate the standard?
>
> My bet is that it will incorrectly free pieces of allocated memory
> when the only references to that memory are in a file (written by
> that process and later read back in by the same process). If lcc-win
> actually handles this, its performance likely sucks if it has to
> scan gigabyte (or worse, terabyte) files for pointer references.
> I think the standard also allows, under the right circumstances,
> for pointers to be *encrypted*, then stored in a file, and later
> read back, decrypted, and used.
It is possible for C99.
You change the pointer to intptr_t, encrypt the integer type, write it
to the file, etc.
Malcolm McLean
in how fast his processor is or how much memory it has installed. He wants
to know "what can I do with this computer?"
At the moment the answer is that five year old hardware will watch video
clips on the web perfectly happily, will do wordprocessing with ease, will
play a nice 3d game. So there's no reason to upgrade except maybe for the
game, and not everyone plays 3d video games.
The really interesting question is what new things we will find to do with
computers.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
Flash Gordon
It's possible in C89 as well. You just treat it as an array of unsigned
char!
I can actually see potentially good reasons for us (my company) to store
some pointers in a temporary table in a database on occasion, probably
the only reason we do not do this is that the original author did not
think of it. The database is written in something close to standard C
(record locking being the main issue for standard C).
--
Flash Gordon
Bartc
"Chris Torek" <nos...@torek.net> wrote in message
news:futtj...@news5.newsguy.com...
> In article <Z%tQj.15440$yD2....@text.news.virginmedia.com>
> Bartc <b...@freeuk.com> wrote:
>>I've little idea about GC or how it works ...
>>What happens when [the only pointer to a successful malloc() result]
>>goes out of scope?
>
>>What about a linked list when it's no longer needed? How does GC know
>>that,
>>do you tell it? And it knows where all the pointers in each node are. ...
> Suppose, for instance, we have a table somewhere of "all allocated
> blocks" (whether this is a list of malloc()s made into an actual . . .
> To do a full GC, we run through the table and clear all the
> "referenced" bits. Then, we use some sort of System Magic to find
> all "root pointers". In C, this could be "every address register,
Probably I haven't fully understood, but are you saying something like:
"Scan through all the memory areas that C can store values in (static areas,
automatic (eg. stack) areas, and you're saying registers too), but ignore
heap areas at first.
And look for a value that, if it happens to be a pointer, points into one of
the allocated areas in this table. Then you can extend the search to that
block too."
OK, the bit I have trouble with is: how does GC know if a value in memory is
a pointer, and not an int, character string, float etc that by coincidence
has a bit-pattern that is in the address range of an allocated block?
--
Bartc
Ben Bacarisse
> OK, the bit I have trouble with is: how does GC know if a value in memory is
> a pointer, and not an int, character string, float etc that by coincidence
> has a bit-pattern that is in the address range of an allocated
> block?
Mostly (in C) they don't. Anything that looks like it *might* be a
pointer is treated as if it were one. The term "conservative GC" is
sometimes used for this behaviour.
--
Ben.
CBFalconer
> Gordon Burditt wrote:
>
... snip unattributed quotes about GC systems ...
>
>> My bet is that it will incorrectly free pieces of allocated memory
>> when the only references to that memory are in a file (written by
>> that process and later read back in by the same process). If
>> lcc-win actually handles this, its performance likely sucks if it
>> has to scan gigabyte (or worse, terabyte) files for pointer
>> references. I think the standard also allows, under the right
>> circumstances, for pointers to be *encrypted*, then stored in a
>> file, and later read back, decrypted, and used.
>>
>> something eligible to be freed.
>>
>> I don't consider this to be a fatal flaw for GC in general or
>> this implementation in particular, as storing pointers in files
>> is relatively unusual. But a standards-compliant GC has to
>> deal with it.
>
> As GC hasn't been defined by the standard yet, we can't say. For
> all we know WG14 might decide to excuse GC from scanning for
> pointers in files and similar stuff. Right now using a GC is
> non-conforming simply because the standard attempts no
> definition for it.
Actually the available systems are conforming, because the complete
source code for the GC mechanism is published, and can be written
in purely standard C. However the resulting mechanism is not a
replacement for the malloc/free system, even though it uses it,
because the result is a non-conforming system.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Dann Corbit
news:45SdndG-TN-FpY_V...@comcast.com...
> "jacob navia" <ja...@nospam.com> wrote in message
> news:fusi33$e0n$1...@aioe.org...
>>
>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
>> gaining in popularity and which not:
>>
>> <quote>
>> DDJ: Which languages seem to be losing ground?
>>
>> PJ: C and C++ are definitely losing ground. There is a simple explanation
>> for this. Languages without automated garbage collection are getting out
>> of fashion. The chance of running into all kinds of memory problems is
>> gradually outweighing the performance penalty you have to pay for garbage
>> collection.
>> <end quote>
>>
>>
>> It really helps.
>
> its not mandatory, I see absolutely nothing wrong with including a
> full-blown GC in your compiler package.
As long as it is possible to turn it off, I have no problem with it either.
On the other hand, if it just runs *period* I have a big problem with it.
Bartc
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:878wz07...@bsb.me.uk...
And I thought it was doing something clever!
--
Bartc
Chris Thomasson
news:Z%tQj.15440$yD2....@text.news.virginmedia.com...
>
> "jacob navia" <ja...@nospam.com> wrote in message
> news:fusi33$e0n$1...@aioe.org...
>>
>> In an interviw with Dr Dobbs, Paul Jansen explains which languages are
>> gaining in popularity and which not:
>>
>> <quote>
>> DDJ: Which languages seem to be losing ground?
>>
>> PJ: C and C++ are definitely losing ground. There is a simple explanation
>> for this. Languages without automated garbage collection are getting out
>> of fashion. The chance of running into all kinds of memory problems is
>> gradually outweighing the performance penalty you have to pay for garbage
>> collection.
>> <end quote>
>>
>> lcc-win has been distributing a GC since 2004.
>
> but how it knows what goes on in the program).
>
> What happens in this code fragment:
>
> void fn(void) {
> int *p = malloc(1236);
> }
>
> when p goes out of scope? (Presumably some replacement for malloc() is
> used.)
A compiler can optmize this away. Even if you did:
extern fne(void* const);
void fn(void) {
void* const buf1 = malloc(1236);
if (buf1) {
void* const buf2 = malloc(1236);
if (buf2) {
L1: fne(buf1);
L2: fne(buf2);
}
}
}
If compiler can detect that 'fne()' does not cache a pointer somewhere, it
can possibly detect that 'buf1' goes out of scope at 'L2'. The GC would need
to run a cycle to act on this information. It would be nice if a compiler
could inject calls to free:
void fn(void) {
void* const buf1 = malloc(1236);
if (buf1) {
void* const buf2 = malloc(1236);
if (buf2) {
L1: fne(buf1);
Inject: free(buf1);
L2: fne(buf2);
Inject: free(buf2);
}
}
}
And the compiler creates a new file, and I can inspect the calls to free to
see if the compiler did a good job before I compile it. Would that be
feasible?
> What about a linked list when it's no longer needed? How does GC know
> that, do you tell it? And it knows where all the pointers in each node
> are. I can think of a dozen ways to confuse a GC so it all sounds like
> magic to me, if it works.
Some GC implementations that will actually scan the stack of all application
threads for pointers into its managed heaps, and attempt to follow all the
links to NULL. If there are no global pointers to an object and no local
pointers in any threads stack, well, it means that its has been rendered
into a persistent quiescent state.
Chris Torek
>> all "root pointers".
In article <uZGQj.15640$yD2....@text.news.virginmedia.com>
Bartc <b...@freeuk.com> wrote:
>Probably I haven't fully understood, but are you saying something like:
>
>"Scan through all the memory areas that C can store values in (static areas,
>automatic (eg. stack) areas, and you're saying registers too), but ignore
>heap areas at first.
>
>And look for a value that, if it happens to be a pointer, points into one of
>the allocated areas in this table. Then you can extend the search to that
>block too."
Right. (Using a suitable definition for "heap areas", anyway.)
>OK, the bit I have trouble with is: how does GC know if a value in memory is
>a pointer, and not an int, character string, float etc that by coincidence
>has a bit-pattern that is in the address range of an allocated block?
As I think Ben said, "it doesn't". It just has to assume the worst:
if something "might be" a pointer, it "is" a pointer, for the purpose
of the GC.
In other languages, the collector has more information, and can
really tell which things are pointers. GCs thus work better in
those other languages. Of course, it is also the case that in a
language designed with garbage collection in mind, one can dispense
with huge amounts of ugliness found in C (and C++ and other "non-GC"
languages with dynamic allocation) that really exists only because
GC does not (exist). So if you want to work with GC, you probably
should be working with a language other than C (or C++ or any of
those other "non-GC" languages).
(It does not hurt if those languages offer inter-language conventions
so that one can hook up "C modules" for places where C's lack of
dynamic typing, exceptions, reflection, object-orientation, matrix
operations, etc., all turn out to be strengths instead of weaknesses.
Of course, even calling them "C modules" is a bit of a stretch, since
C does not really work in terms of "modules". :-) )
Richard Tobin
Bartc <b...@freeuk.com> wrote:
>> That's why the toast crumbs keep accumulating at the bottom.
>There might be a little tray that you can slide out to remove the crumbs
>easily.
In my experience it's a little tray that you can slide out to dump all
the crumbs back into the toaster.
-- Richard
--
:wq
cr88192
yeah...
my compiler is not caught up yet though...
partly, it is that there are a few hidden snares in x86-64 that makes more
than a little difficulty for targeting it with a compiler (or, at least with
the calling convention used on Linux...).
IMO, Win64 has a better calling convention (it is much simpler to
target...).
more so, at least, I would want arguments for vararg functions (or, at
least, the varargs) to be passed on the stack...
sadly, one can't change the calling convention without making a big ugly
mess wrt linking to externally compiled code...
> --
> Ian Collins.
cr88192
"Malcolm McLean" <regn...@btinternet.com> wrote in message
news:EZKdnfAdvoPkno7V...@bt.com...
maybe merging 3D gaming and porn...
some Sci-Fi style immersive interface with tactile feedback (for example,
tactile stimulation combined with force feedback), with high quality models
derived from actual data...
or, for the lazy, a partial option consisting of a headset and hands-free
stimulator...
(or, maybe an MMOG where people can get somehow pulled into the game, and if
they die in the game they die in reality...).
ok, yes, all of this is a bunch of generic Sci-Fi cliches, but yeah...
Chris Thomasson
[...]
> If compiler can detect that 'fne()' does not cache a pointer somewhere, it
> can possibly detect that 'buf1' goes out of scope at 'L2'. The GC would
> need to run a cycle to act on this information. It would be nice if a
> compiler could inject calls to free:
>
>
> void fn(void) {
> void* const buf1 = malloc(1236);
> if (buf1) {
> void* const buf2 = malloc(1236);
> if (buf2) {
> L1: fne(buf1);
> Inject: free(buf1);
> L2: fne(buf2);
> Inject: free(buf2);
> }
> }
> }
>
[...]
Whoops! Of course there is a memory leak!
Let me fix that:
void fn(void) {
void* const buf1 = malloc(1236);
if (buf1) {
void* const buf2 = malloc(1236);
if (buf2) {
L1: fne(buf1);
Inject: free(buf1);
L2: fne(buf2);
Inject: free(buf2);
} else {
Inject: free(buf1);
}
}
}
There, now 'buf1' does not get leaked when an allocation attempt fails for
'buf2'.
ARGH!
Hallvard B Furuseth
>Bartc <b...@freeuk.com> writes:
>> What happens in this code fragment:
>>
>> void fn(void) {
>> int *p = malloc(1236);
>> }
>>
>> when p goes out of scope? (Presumably some replacement for malloc()
>> is used.)
>
> I think this one is a reayll simply example. And I would be very
> suprised if any GC would fail on this simple thing.
Sure it could. p might have representation 0x6f726c64, which is the
same as the ASCII representation of "orld", from the program's output
text "Hello, world!". Very often that's OK. Sometimes it's not.
Consider a host with N-bit pointers and a program using 2**(N-2) bytes
of memory: Every random N-bit value, considered as a potential pointer,
has close to 1/4 chance of pointing into a live object. And if pointers
have 1-byte alignment on this host then most bytes of memory are part of
sizeof(pointer) "potential pointers". E.g. if you have an array of 2
values 0x1234 and 0x5678, then 0x3456 is also a potential pointer.
It's usually not that bad since words do not contain random values -
they'll normally cluster around small integers, representations of ASCII
letters, etc. But not all programs behave that way. And each piece of
uncollected garbage will keep all the other garbage it recursively
points at, uncollected.
In any case, using close to 4G of memory with garbage collection on a
32-bit host with 1-byte aligned pointers is not the brightest idea.
Switch to a host with 64-bit pointers and you are better off, in
particular if the implementation is aware of potential GC and avoids
heap addresses that match common memory patterns (small positive and
negative integers, ASCII text etc).
Also the program can help the collector by zeroing out unused pointer
values (or all unused values). Sometimes that's no less work than a
free(), but it does relieve the program of remembering if there are
other pointers to the data.
--
Hallvard
George Peter Staplin
That's how C works with a conservative GC, such as the Boehm GC. With
an accurate GC there are no such limitations. All root variables are
known with an accurate GC, so that once all references from the roots to
an address or address range go away, the memory can be reused/released.
Unfortunately making an accurate GC for C would require compiler
support, and even then it would break in some cases due to the design of
C.
Some people are content with a few false references and thus the Boehm
GC works for them. I hope that their software isn't used for something
involving human lives, and that the allocations retained aren't large.
George
jacob navia
> Some people are content with a few false references and thus the Boehm
> GC works for them. I hope that their software isn't used for something
> involving human lives, and that the allocations retained aren't large.
>
Incredible. And you will trust your life to the ability of a programmer
to avoid bugs in MANUALLY done memory management?
I would prefer GC at any time!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
santosh
> George Peter Staplin wrote:
>> Some people are content with a few false references and thus the
>> Boehm
>> GC works for them. I hope that their software isn't used for
>> something involving human lives, and that the allocations retained
>> aren't large.
>>
>
> Incredible. And you will trust your life to the ability of a
> programmer to avoid bugs in MANUALLY done memory management?
>
> I would prefer GC at any time!
In mission critical contexts deterministic behaviour (at least from the
software POV) is necessary. C with GC is not deterministic. I'm sure
you know this. Remember, desktops and servers are only one
(diminishing) of the many domains where C is used.
Flash Gordon
> George Peter Staplin wrote:
>> Some people are content with a few false references and thus the Boehm
>> GC works for them. I hope that their software isn't used for
>> something involving human lives, and that the allocations retained
>> aren't large.
>>
>
> Incredible. And you will trust your life to the ability of a programmer
> to avoid bugs in MANUALLY done memory management?
>
> I would prefer GC at any time!
Actually, I would prefer safety critical software not use *any*
allocated memory, no recursion, and the maximum call depth and memory
usage calculated and *proved* to fit in the available memory. I've done
a significant amount of non-safety critical work with these restrictions
so for certain classes of application it is entirely possible.
--
Flash Gordon
Eligiusz Narutowicz
Why? If you are able to be programming and testing properly your
seemingly random restrictions seem more tailored to a low quality C
programmer than to produce a sensible and reliable program. Mallocing
memory is not dangerous at all when its correctly handled. The same for
recursion. I would suggest more rigour in your design and testing than
silly rules such as you mention.
Bartc
"Eligiusz Narutowicz" <eligius...@hotmail.com> wrote in message
news:fv24na$cqu$1...@registered.motzarella.org...
Malloc can run out of memory.
Not using malloc can't! So the program can't fail for that reason.
--
Bartc
santosh
I think the point that Flash is making is that malloc *can* fail. In a
fault-intolerant environment, you want to keep chances of failures to a
minimum. In a important section of code, what should be done if malloc
returns NULL due to some reason or the other, like say memory
fragmentation? The options open to desktop or general purpose programs
(like calling exit, abort etc.) may not be acceptable at in some
contexts. Recursion *can* be used safely, but again it simply opens up
the program to more chances of failure and consumes excessive resources
in a very likely resource constrained environment.
So I would say that for certain limited types of applications Flash's
recommendations are entirely sensible.
Eligiusz Narutowicz
Malloc can also break down when the power goes off too. In a well
designed program on a properly specced piece of HW it does not run out
of memory. So the natural extension of your reply is "do not use malloc
as it may run out of memory". I wonder if C is being for you?
santosh
In a really safety critical program sufficient memory for maximum
expected usage must be present as part of system design. Otherwise,
instead of malloc failing, we will simply get the even more
unmanageable stack memory exhaustion.
jacob navia
> In a well
> designed program on a properly specced piece of HW it does not run out
> of memory. So the natural extension of your reply is "do not use malloc
> as it may run out of memory". I wonder if C is being for you?
Of course it may run out of memory if for some reason (BUG) there is
a memory leak.
Of course this never happens to you, Mr Superman. (Unless you run into
Kryptonite)
What people like you fail to understand is that a moderately complex
piece of software can't be tested exhaustively since the exponential
growth of the combinations of input parameters, interrupts, timing
considerations, possible paths through the software etc makes exhaustive
testing impossible.
What can be done is to test each module as far as the budget goes,
test all the modules in simulated real life conditions, etc.
But no amount of testing will make bugs go away, specially in C,
and SPECIALLY using manually garbage collection!!!
In manual GC (malloc/free) each allocation/release becomes a point of
failure. Using a GC, the GC can be the point of failure but when the GC
is certified, all other points of failures disappear.
Obviously you haven't read the abundant literature about software
testing, and apparently you are ignorant of all the problems associated
with manual GC. It is therefore with the usual ARROGANCE of the people
that think that know everything that you dare to ask:
<< I wonder if C is for you >>
as if you were some kind of demigod, that never makes mistakes.
You know nothing about the subject matter guy!
Bartc
What difference will changing language make? If dynamic memory is being used
in a complex way then it is conceivable that memory can become full whatever
the language. At least in C there is some choice.
Imagine a graph showing heap memory usage from 0% to 100% over runtime.
There will be peaks and troughs. Some peaks can be near 100%. But can you
prove that it will not hit 100%? Ever? On any combination of programs that
might be sharing the memory?
If you take dynamic memory out of the equation (or get the dynamic
allocations out of the way right at the start, in a proven setup) then you
forcing other techniques to be used so that you can avoid that problem.
> Malloc can also break down when the power goes off too.
Where it's important, then there are ways of taking care of that.
--
Bartc
santosh
<snip>
> In manual GC (malloc/free) each allocation/release becomes a point of
> failure. Using a GC, the GC can be the point of failure but when the
> GC is certified, all other points of failures disappear.
<snip>
What exactly do you mean by a "failure" in a GC? Is failing to collect
storage for which all references have been lost a failure? If this is
so, and in due course the program fails to run because of an
out-of-memory situation due to the GC failing to collect blocks that it
should have, would you still say that such software can be reliably
used in safety or performance critical contexts?
Also how exactly do you propose to certify a GC? Just because it works
for some set of programs doesn't mean that it will work for all
possible programs.
Flash Gordon
You also need to be able to prove with a certain degree of rigour (which
varies depending on how safety critical the SW is and what else there is
to prevent injury or loss of life).
> In a important section of code, what should be done if malloc
> returns NULL due to some reason or the other, like say memory
> fragmentation?
Or simply a bug in the malloc/free implementation. So you would have to
either get the library provider to get their library tested to the
relevant standards (such testing is expensive, even more so if it was
not designed to meet those standards in the first place) or you have to
take responsibility for it and prove the library.
> The options open to desktop or general purpose programs
> (like calling exit, abort etc.) may not be acceptable at in some
> contexts.
Indeed. How do you fancy being in (or under) a military jet flying at
night 30 feet above the ground when the pilots night vision system
decides to reboot? You could be dead in under a second.
> Recursion *can* be used safely, but again it simply opens up
> the program to more chances of failure and consumes excessive resources
> in a very likely resource constrained environment.
Even if it is not tightly constrained (where I worked there was a
standard requirement of 50% free resources to allow for future
enhancements) it still makes it harder to *prove* that it is safe.
> So I would say that for certain limited types of applications Flash's
> recommendations are entirely sensible.
There are a lot of applications where it makes sense, and a lot more
where it doesn't make sense. Safety critical (and it was someone else
who mentioned "life depending on it") would be at the top of my list of
things where it makes sense.
I would be interested to here what the MISRA standard said about
allocated memory and recursion, I suspect it might be forbidden or at
least highly constrained there too.
Oh, and when I worked in the defence industry we had these restrictions.
For the type of applications I worked on it was not a problem and even
without the restrictions there was only one application in 15 years
where I might have considered using malloc, and I can't think of any
where recursion would have been appropriate.
For "normal" applications (like those I work on now) I will happily use
malloc/realloc/free, I might consider garbage collection if it was part
of the standard, and I think nothing of mutually recursive functions (we
have very good reason for a() calls b() calls c() calls a() and even
more complex things).
--
Flash Gordon
jacob navia
> jacob navia wrote:
>
> <snip>
>
>> In manual GC (malloc/free) each allocation/release becomes a point of
>> failure. Using a GC, the GC can be the point of failure but when the
>> GC is certified, all other points of failures disappear.
>
> <snip>
>
> What exactly do you mean by a "failure" in a GC?
1) Failing to collect an unused block
2) Failure to realize that a released block was actually in use
3) Failure to compact memory
> Is failing to collect
> storage for which all references have been lost a failure?
Yes.
> If this is
> so, and in due course the program fails to run because of an
> out-of-memory situation due to the GC failing to collect blocks that it
> should have, would you still say that such software can be reliably
> used in safety or performance critical contexts?
>
Of course not. And I am not proposing that a conservative GC
that is OK for desktop applications be used in an airplane software.
But a GC can be built into the compiler, or programmed specifically
for the application, etc.
> Also how exactly do you propose to certify a GC?
As all other certifications process for complex software go.
> Just because it works
> for some set of programs doesn't mean that it will work for all
> possible programs.
>
Exactly. It is very difficult!
Hallvard B Furuseth
>Hallvard B Furuseth wrote:
>> Sure it could. p might have representation 0x6f726c64, which is the
>> same as the ASCII representation of "orld", from the program's output
>> text "Hello, world!". Very often that's OK. Sometimes it's not.
>
> That's how C works with a conservative GC, such as the Boehm GC. With
> making an accurate GC for C would require compiler support, and even
> then it would break in some cases due to the design of C.
True, I should have mentioned that I was talking about GC in C (or a
normal C implementation anyway), which doesn't store enough type
information for the collector to know what is a pointer and what isn't.
--
Hallvard
CBFalconer
> George Peter Staplin wrote:
>
>> Some people are content with a few false references and thus the
>> Boehm GC works for them. I hope that their software isn't used
>> for something involving human lives, and that the allocations
>> retained aren't large.
>
> Incredible. And you will trust your life to the ability of a
> programmer to avoid bugs in MANUALLY done memory management?
Definitely yes. I pay attention to these things, and have produced
lots of software, embedded and otherwise, that accurately handles
memory with malloc and equivalents. I know what is happening. And
the lives of others depended on that software.
I prefer to trust my own judgment than that of some unknown.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Eligiusz Narutowicz
> Eligiusz Narutowicz wrote:
>> In a well
>> designed program on a properly specced piece of HW it does not run out
>> of memory. So the natural extension of your reply is "do not use malloc
>> as it may run out of memory". I wonder if C is being for you?
>
> Of course it may run out of memory if for some reason (BUG) there is
> a memory leak.
Yes - this is true of all programs in all languages.
>
> Of course this never happens to you, Mr Superman. (Unless you run into
> Kryptonite)
I'm not sure what you are being aggressive for. I am just saying that a
well tested and debugged program does not lose memory - do yours?
Certainly using GC to cover sloppy programming is no remedy I think.
>
> What people like you fail to understand is that a moderately complex
> piece of software can't be tested exhaustively since the exponential
> growth of the combinations of input parameters, interrupts, timing
> considerations, possible paths through the software etc makes exhaustive
> testing impossible.
What can be tested and checked is a well marshalled malloc/free
access. God knows I have worked on enough C progrms which are large and
do not leak memory. Have I made bugs? Of course.
>
> What can be done is to test each module as far as the budget goes,
> test all the modules in simulated real life conditions, etc.
>
> But no amount of testing will make bugs go away, specially in C,
> and SPECIALLY using manually garbage collection!!!
I think - sorry, I know, you are wrong. You are basically saying you
can not make a bug free program using malloc. This is clearly not the
truth.
>
> In manual GC (malloc/free) each allocation/release becomes a point of
> failure. Using a GC, the GC can be the point of failure but when the
> GC
> is certified, all other points of failures disappear.
>
> Obviously you haven't read the abundant literature about software
> testing, and apparently you are ignorant of all the problems associated
> with manual GC. It is therefore with the usual ARROGANCE of the people
> that think that know everything that you dare to ask:
>
> << I wonder if C is for you >>
>
> as if you were some kind of demigod, that never makes mistakes.
>
> You know nothing about the subject matter guy!
Actually I have been a professional C programmer for approximately 20
years. I am acutely aware of the issues and pitfalls involedv in C
programming.
I think you have misunderstood me.
I am saying this - one does not "not use malloc" because its possible to
use it badly. Do you not drive a car because its possibly to crash it if
you make a mistake?
Eligiusz Narutowicz
> jacob navia wrote:
>> George Peter Staplin wrote:
>>
>>> Some people are content with a few false references and thus the
>>> Boehm GC works for them. I hope that their software isn't used
>>> for something involving human lives, and that the allocations
>>> retained aren't large.
>>
>> Incredible. And you will trust your life to the ability of a
>> programmer to avoid bugs in MANUALLY done memory management?
>
> Definitely yes. I pay attention to these things, and have produced
> lots of software, embedded and otherwise, that accurately handles
> memory with malloc and equivalents. I know what is happening. And
> the lives of others depended on that software.
>
> I prefer to trust my own judgment than that of some unknown.
I too am confused why Jacob thinks it is not possible to use malloc/free
in a proven, tested and bug free manner. it is a surprise to me and I
wonder how all these C programs over the years are still working so well
- including Gnome and the Linux kernel.
Personally I do not like GC - I think it encourages lazy thinking and if
you then go back to a non GC C environment then possibly this lazy
thinkings will be causing bugs.
santosh
[ ... ]
> I prefer to trust my own judgment than that of some unknown.
Now if everybody said the same...
santosh
<snip>
> Personally I do not like GC - I think it encourages lazy thinking and
> if you then go back to a non GC C environment then possibly this lazy
> thinkings will be causing bugs.
I would be interested to hear your views on what you mean by "lazy
thinking" in this context.
Personally I consider it lazy programming (in a manual malloc -> free
context) to free some memory but not others. With a GC of course you
don't free anything at all. However a poor GC which fails to pick up
eligible objects may itself be called "lazy" I suppose. :-)
Also (at least in the context of C programming) even if one uses a GC
other resources like file streams, file descriptors, mmap'ed objects
still need to be freed manually. Typically they are much scarcer than
memory too! So it pays (IMHO) to get into the practise of closely
tracking all your program resources early on, if you ever want to be a
good C or C++ programmer.
Eligiusz Narutowicz
Obviously it *can* fail. A programmers job is to ensure it doesnt in a
properly configured system. And not using it is not a solution.
> fault-intolerant environment, you want to keep chances of failures to a
> minimum. In a important section of code, what should be done if malloc
> returns NULL due to some reason or the other, like say memory
> fragmentation? The options open to desktop or general purpose programs
> (like calling exit, abort etc.) may not be acceptable at in some
> contexts. Recursion *can* be used safely, but again it simply opens up
> the program to more chances of failure and consumes excessive resources
> in a very likely resource constrained environment.
>
> So I would say that for certain limited types of applications Flash's
> recommendations are entirely sensible.
Very, very, very , very limited yes.
But if you program for worst case then you might as well give up in my
opinion.
Eligiusz Narutowicz
> Eligiusz Narutowicz wrote:
>
> <snip>
>
>> Personally I do not like GC - I think it encourages lazy thinking and
>> if you then go back to a non GC C environment then possibly this lazy
>> thinkings will be causing bugs.
>
> I would be interested to hear your views on what you mean by "lazy
> thinking" in this context.
Very easy to define. Not thinking about memory allocation and
deallocations and using it like a free never ending resource with it
being given back when you dont need it. It encourages poor flow and
optimizations I think and is why MOST Java programs I come across over
the years are buggy, slow and use too much memory.
>
> Personally I consider it lazy programming (in a manual malloc -> free
> context) to free some memory but not others.
So do I. But worse. It is rubbish, buggy programming.
> With a GC of course you
> don't free anything at all. However a poor GC which fails to pick up
> eligible objects may itself be called "lazy" I suppose. :-)
Of course. Personally I am using C for a reason - efficiency. GC removes
a lot of that.
>
> Also (at least in the context of C programming) even if one uses a GC
> other resources like file streams, file descriptors, mmap'ed objects
> still need to be freed manually. Typically they are much scarcer than
> memory too! So it pays (IMHO) to get into the practise of closely
> tracking all your program resources early on, if you ever want to be a
> good C or C++ programmer.
You seem to be repeating what I say.
Hallvard B Furuseth
Different kind of risk.
With GC in safety-critical programs, the question is "will this be the
time the collector pauses the program for a dangerously long time in
order to do its job, or fails to collect enough memory?"
With CBFalconer-code the question is "has cbfalconer.home.att.net
recently been outsourced to some kid in India?"
This is why GC is the best choice for safety-critical programs nowadays.
--
Hallvard
Eric Sosman
> santosh wrote:
>> [...]
>> If this is
>> so, and in due course the program fails to run because of an
>> out-of-memory situation due to the GC failing to collect blocks that it
>> should have, would you still say that such software can be reliably
>> used in safety or performance critical contexts?
>>
>
> Of course not. And I am not proposing that a conservative GC
> that is OK for desktop applications be used in an airplane software.
Well, you *did* ridicule George Peter Staplin, saying
:> Incredible. And you will trust your life to the ability of a
:> programmer to avoid bugs in MANUALLY done memory management?
:>
:> I would prefer GC at any time!
... with the clear implication that automatic garbage collection
*is* safe for use in software on which lives depend. Would you
care to explain the apparent contradiction between your responses
to Mr. Staplin and to santosh?
>> Also how exactly do you propose to certify a GC?
>
> As all other certifications process for complex software go.
You described *that* process to Eligiusz Narutowicz, saying
:> [...] a moderately complex piece of software can't be tested
:> exhaustively since the exponential growth of the combinations
:> of input parameters, interrupts, timing considerations, possible
:> paths through the software etc makes exhaustive testing impossible.
:> [...]
:> But no amount of testing will make bugs go away, [...]
Since a garbage collection system is "a moderately complex
piece of software," it follows that Program P plus GC has more
bugs than Program P standing by itself.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Bartc
> What can be tested and checked is a well marshalled malloc/free
> access. God knows I have worked on enough C progrms which are large and
> do not leak memory.
I hadn't even thought about memory leaks. Only that dynamic memory is more
complex and therefore full of nasty surprises.
> santosh <santo...@gmail.com> writes:
>> I think the point that Flash is making is that malloc *can* fail. In a
>
> Obviously it *can* fail. A programmers job is to ensure it doesnt in a
> properly configured system. And not using it is not a solution.
Compare these two pieces of code:
(1)
char array[10000];
(2)
char *array;
array=malloc(10000);
if (array==NULL) puts("YOU'RE DEAD"); /* what else can it do? */
Which would most people prefer in their critical software?
No matter how brilliant a programmer you are, you have to allow for the
possibility of malloc() failing for some inexplicable reason.
--
Bartc
Eligiusz Narutowicz
Its nothing to do with being a brilliant programmer. Most "real
programs" use malloc to dynamically allocate memory which is then
retained and passed around functions to be reused/processed - in
addiition the size of the malloc often alters depending on process
parameters.
I'm sorry but I do not see or agree with this sudden "malloc is evil"
trend. Malloc usage is not trivial. Neither is good systems programming.
jacob navia
Obvious. The GC is as untestable as any other big piece of software.
But when you use it, you are using a piece of software that can be
tested in many applications and much more situations than a specific
malloc/free combination. It is MODULE that can be tested separatedly.
Malloc/free combinations are embedded in your software and can't be
tested independently from it. This makes it much more difficult to test.
In some environments, a conservative GC is not allowed because of the
small memory leak that it implies. Then, another type of GC can be
used, that is reused over and over again in certain applications with
certain patterns of allocation/deallocation.
Many types of GC have been used, and a GC with compiler support would be
much more precise than a conservative one like Boehm's.
jacob navia
Obvious. malloc is not "evil". But it is error prone, and can fail
if there is a memory leak in the system. Memory leaks can happen in a GC
environment too.
As you know, if you hold a pointer to an object, the GC will not touch
it. But if you hold a pointer to an unneeded object without you
realizing it you have a memory leak WITH A GC!
I am not saying that GC is the best since sliced bread. I am saying that
it is a technique that can SIMPLIFY programming. And by simplifying
programming it makes it less error prone.
Eric Sosman
> Eric Sosman wrote:
>> jacob navia wrote:
>> :> But no amount of testing will make bugs go away, [...]
>>
>> Since a garbage collection system is "a moderately complex
>> piece of software," it follows that Program P plus GC has more
>> bugs than Program P standing by itself.
>>
>
> Obvious. The GC is as untestable as any other big piece of software.
All right, "The GC is untestable."
> But when you use it, you are using a piece of software that can be
> tested in many applications and much more situations than a specific
> malloc/free combination. It is MODULE that can be tested separatedly.
All right, "The GC can be tested."
Wotcher.
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
> jacob navia wrote:
>> Eric Sosman wrote:
>>> jacob navia wrote:
>>> :>
>>> :> But no amount of testing will make bugs go away, [...]
>>>
>>> Since a garbage collection system is "a moderately complex
>>> piece of software," it follows that Program P plus GC has more
>>> bugs than Program P standing by itself.
>>>
>>
>> Obvious. The GC is as untestable as any other big piece of software.
>
> All right, "The GC is untestable."
>
Untestable EXHAUSTIVELY.
If you are going to play word games (like the regulars love to do)
just forget this discussion.
>> But when you use it, you are using a piece of software that can be
>> tested in many applications and much more situations than a specific
>> malloc/free combination. It is MODULE that can be tested separatedly.
>
> All right, "The GC can be tested."
Can be BETTER tested than a malloc/free approach since it is SEPARATED
FROM THE APPLICATION.
It can be tested in ISOLATION, therefore the range of tests that can be
used is more extensive.
That was my argument that you didn't even bother to argue.
Eligiusz Narutowicz
> Eric Sosman wrote:
>> jacob navia wrote:
>>> Eric Sosman wrote:
>>>> jacob navia wrote:
>>>> :>
>>>> :> But no amount of testing will make bugs go away, [...]
>>>>
>>>> Since a garbage collection system is "a moderately complex
>>>> piece of software," it follows that Program P plus GC has more
>>>> bugs than Program P standing by itself.
>>>>
>>>
>>> Obvious. The GC is as untestable as any other big piece of software.
>>
>> All right, "The GC is untestable."
>>
>
> Untestable EXHAUSTIVELY.
>
> If you are going to play word games (like the regulars love to do)
> just forget this discussion.
>
>>> But when you use it, you are using a piece of software that can be
>>> tested in many applications and much more situations than a specific
>>> malloc/free combination. It is MODULE that can be tested separatedly.
>>
>> All right, "The GC can be tested."
>
> Can be BETTER tested than a malloc/free approach since it is SEPARATED
> FROM THE APPLICATION.
This is of course total rubbish. One can wrap malloc/free and log
mallocs and frees easily enough. You seem to be intent on making it into
some sort of impossible task. History states that it isn't. There are
plenty of reliable and long lasting C projects you know!
> It can be tested in ISOLATION, therefore the range of tests that can be
> used is more extensive.
>
> That was my argument that you didn't even bother to argue.
Testing in isolation is immaterial. It has to work with the rest of the
system. Look up Heisenbugs.
http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs
For my thinking using GC in C I might as well have chosen Java in the
first place.
Eric Sosman
> Eric Sosman wrote:
>> jacob navia wrote:
>>>
>>> But when you use it, you are using a piece of software that can be
>>> tested in many applications and much more situations than a specific
>>> malloc/free combination. It is MODULE that can be tested separatedly.
>>
>> All right, "The GC can be tested."
>
> Can be BETTER tested than a malloc/free approach since it is SEPARATED
> FROM THE APPLICATION.
>
> It can be tested in ISOLATION, therefore the range of tests that can be
> used is more extensive.
How can you test a garbage collector "in isolation," when
there's nothing to generate garbage for it? Test harnesses?
Why couldn't test harnesses also be written and run for the
(far simpler) malloc() suite of functions?
> That was my argument that you didn't even bother to argue.
It didn't occur to me that rational argument would make
any impression on you.
By the way, you still haven't explained the contradiction
between your replies to Staplin ("GC is safe enough to entrust
one's life to") and to santosh ("I never said GC should be
used in airplane software").
--
Eric Sosman
eso...@ieee-dot-org.invalid
jacob navia
> jacob navia <ja...@nospam.com> writes:
>
>> Eric Sosman wrote:
>>> jacob navia wrote:
>>>> Eric Sosman wrote:
>>>>> jacob navia wrote:
>>>>> :>
>>>>> :> But no amount of testing will make bugs go away, [...]
>>>>>
>>>>> Since a garbage collection system is "a moderately complex
>>>>> piece of software," it follows that Program P plus GC has more
>>>>> bugs than Program P standing by itself.
>>>>>
>>>> Obvious. The GC is as untestable as any other big piece of software.
>>> All right, "The GC is untestable."
>>>
>> Untestable EXHAUSTIVELY.
>>
>> If you are going to play word games (like the regulars love to do)
>> just forget this discussion.
>>
>>>> But when you use it, you are using a piece of software that can be
>>>> tested in many applications and much more situations than a specific
>>>> malloc/free combination. It is MODULE that can be tested separatedly.
>>> All right, "The GC can be tested."
>> Can be BETTER tested than a malloc/free approach since it is SEPARATED
>> FROM THE APPLICATION.
>
> This is of course total rubbish. One can wrap malloc/free and log
> mallocs and frees easily enough.
But this is nonsense. If you "wrap" malloc
char *a = mymalloc(sizeof(buf)+sizeof(data));
.....
myfree(a);
The CALLS are embedded in the application anyway. They can't
be tested OUTSIDE and with a wider range of tests.
You seem to be intent on making it into
> some sort of impossible task. History states that it isn't. There are
> plenty of reliable and long lasting C projects you know!
>
>> It can be tested in ISOLATION, therefore the range of tests that can be
>> used is more extensive.
>>
>> That was my argument that you didn't even bother to argue.
>
> Testing in isolation is immaterial.
Excuse me but then you do not know anything about software testing.
The FIRST thing you do is to test separate modules independently,
THEN test the whole.
> It has to work with the rest of the
> system. Look up Heisenbugs.
>
But Heisenbugs can only be discovered if you see them AFTER you
have tested individually!
> http://en.wikipedia.org/wiki/Heisenbug#Heisenbugs
>
> For my thinking using GC in C I might as well have chosen Java in the
> first place.
And what's wrong with Java?
It has many good ideas, among others the garbage collector, that was
copied from Lisp, one of the first languages to offer a GC. I am not
a language fanatic and I see the pros and cons of things.
Gordon Burditt
>
>1) Failing to collect an unused block
I'd give garbage collection a break here and not require it to
collect until another block is requested, or until it needs another
block from the OS. And C implementations that don't know what's
*in* memory blocks may get fooled by data that isn't a pointer
looking like one.
>2) Failure to realize that a released block was actually in use
Yes, this is a really nasty problem and would be an issue in the
"pointers stored in files" or "encrypted pointers" situations.
Fortunately, these are *very* uncommon.
>3) Failure to compact memory
^^^^^^^^^^^^^^^^^^^^^^^^^
So, you're saying that one of the OTHER non-standard-conforming
features of a GC is that you can't use garbage-collectable memory
in a signal handler?
Note I said *use*, not allocate (or free, if explicit freeing is
even possible).
jacob navia
> jacob navia wrote:
>> Eric Sosman wrote:
>>> jacob navia wrote:
> >>>
>>>> But when you use it, you are using a piece of software that can be
>>>> tested in many applications and much more situations than a specific
>>>> malloc/free combination. It is MODULE that can be tested separatedly.
>>>
>>> All right, "The GC can be tested."
>>
>> Can be BETTER tested than a malloc/free approach since it is SEPARATED
>> FROM THE APPLICATION.
>>
>> It can be tested in ISOLATION, therefore the range of tests that can be
>> used is more extensive.
>
> How can you test a garbage collector "in isolation," when
> there's nothing to generate garbage for it?
By generating patterns of allocation that test specific parts of the
collector, thread safety etc etc.
Test harnesses?
Of course. How can you test it if not?
> Why couldn't test harnesses also be written and run for the
> (far simpler) malloc() suite of functions?
>
You can test malloc/free, but you can't test if this malloced piece
of RAM has been freed correctly or not and THAT IS THE POINT HERE!
>> That was my argument that you didn't even bother to argue.
>
> It didn't occur to me that rational argument would make
> any impression on you.
>
It didn't occur to you that arguing, exposing your arguments and
understanding other people's arguments has any sense. You are a
typical regular Mr Sossman. No arguments, just polemic.
> By the way, you still haven't explained the contradiction
> between your replies to Staplin ("GC is safe enough to entrust
> one's life to")
Read again. I said that an automatic process of memory management
(GC) is safer than many calls to malloc/free.
> and to santosh ("I never said GC should be
> used in airplane software").
>
Read again. I said that a CONSERVATIVE GC is not OK for airplane
software because it can leak memory because random correspondence
between pointers and other data in the stack.
Even if you use your error prone malloc/free, you have to do a GC and a
consolidation of free memory anyway!
Ian Collins
> Eligiusz Narutowicz wrote:
>>
>> This is of course total rubbish. One can wrap malloc/free and log
>> mallocs and frees easily enough.
>
> But this is nonsense. If you "wrap" malloc
>
> char *a = mymalloc(sizeof(buf)+sizeof(data));
> myfree(a);
>
> The CALLS are embedded in the application anyway. They can't
> be tested OUTSIDE and with a wider range of tests.
>
provide a logging implementation for testing. Remember it isn't the
allocation functions that are being tested, its the balance of
allocations and frees.
>>
>> Testing in isolation is immaterial.
>
> Excuse me but then you do not know anything about software testing.
> The FIRST thing you do is to test separate modules independently,
> THEN test the whole.
>
Indeed.
--
Ian Collins.
jacob navia
>>> What exactly do you mean by a "failure" in a GC?
>> 1) Failing to collect an unused block
>
> I'd give garbage collection a break here and not require it to
> collect until another block is requested, or until it needs another
> block from the OS.
Yes, that is how the GC works, BUT if you call GC() or you
allocate a block and the collector makes a scan, it SHOULD
ind all the blocks that are not in use! I was referring to those
bugs in the collector.
> And C implementations that don't know what's
> *in* memory blocks may get fooled by data that isn't a pointer
> looking like one.
>
>> 2) Failure to realize that a released block was actually in use
>
> Yes, this is a really nasty problem and would be an issue in the
> "pointers stored in files" or "encrypted pointers" situations.
> Fortunately, these are *very* uncommon.
>
Yes, but I wasn't referring to those, I ws referring that you hold
a legal pointer and even if you hold it the GC frees it because
it misses the pointer in the stack , or fails to scan all globals,
whatever.
>> 3) Failure to compact memory
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> So, you're saying that one of the OTHER non-standard-conforming
> features of a GC is that you can't use garbage-collectable memory
> in a signal handler?
>
Yes you can use it. I was referring to the process of scanning memory
for adjacent blocks and trying to build bigger blocks from scattered
pieces of memory.
Ian Collins
> Eric Sosman wrote:
>
>> Why couldn't test harnesses also be written and run for the
>> (far simpler) malloc() suite of functions?
>>
>
> You can test malloc/free, but you can't test if this malloced piece
> of RAM has been freed correctly or not and THAT IS THE POINT HERE!
>
my other reply.
--
Ian Collins.
Ian Collins
[who said this? Boy you're rude.]
> jacob navia wrote:
>
>> 3) Failure to compact memory
> ^^^^^^^^^^^^^^^^^^^^^^^^^
> So, you're saying that one of the OTHER non-standard-conforming
> features of a GC is that you can't use garbage-collectable memory
> in a signal handler?
>
> Note I said *use*, not allocate (or free, if explicit freeing is
> even possible).
>
No GC used with C can compact the heap.
Where languages are designed to use GC, objects can be moved in memory,
allowing the GC to compact the heap. Thus C with GC looses one of the
key benefits of Garbage Collection.
--
Ian Collins.
Richard Tobin
Ian Collins <ian-...@hotmail.com> wrote:
>No GC used with C can compact the heap.
Not with an off-the-shelf C compiler, at least. It should be possible
to produce a C implementation that reliably knows which locations are
pointers, and have the GC adjust them accordingly. You would have to
impose some more restrictions of the kind that conservative GCs
already have concerning the "hiding" of pointers.
-- Richard
--
:wq
Hallvard B Furuseth
>Gordon Burditt wrote:
>>> 3) Failure to compact memory
>> ^^^^^^^^^^^^^^^^^^^^^^^^^
>> So, you're saying that one of the OTHER non-standard-conforming
>> features of a GC is that you can't use garbage-collectable memory
>> in a signal handler?
>
> Yes you can use it. I was referring to the process of scanning memory
> for adjacent blocks and trying to build bigger blocks from scattered
> pieces of memory.
Join freed memory blocks? A bad malloc/free implementation can fail at
that too.
But that's not compacting. Compacting is when you move used memory and
update all pointers to it, so that many small fragments of freed memory
can get joined into one or few bigger fragments.
One could implement compacting collections in C with indirect pointers:
Keep a table of pointers to live memory blocks. Implement a C pointer
as a pair (table entry, offset into that memory block). When moving a
block of memory, you only need to update the pointer in the table.
--
Hallvard