Garbage collection

[Richard Tobin]

Re: Garbage collection

In article <futh8h$cp7$1@a ioe.org>, jacob navia <jacob@nospam.o rgwrote:

>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

[Keith Thompson]

Re: Garbage collection

jacob navia <jacob@nospam.c omwrites:

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
>representati on 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

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.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

Re: Garbage collection

William Ahern wrote, On 25/04/08 20:33:

user923005 <dcorbit@connx. comwrote:

>On Apr 25, 5:16?am, jacob navia <ja...@nospam.c omwrote:

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

Re: Garbage collection

jacob navia wrote:

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

--
Eric.Sosman@sun .com

[jacob navia]

Re: Garbage collection

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[cr88192]

Re: Garbage collection


"Yunzhong" <gaoyunzhong@gm ail.comwrote in message
news:4e2457ef-e23e-41a5-925c-995bd67ddc78@b6 4g2000hsa.googl egroups.com...

>I don't see C dying out any time soon. The problem with automatic
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.

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]

Re: Garbage collection

On Apr 25, 3:34 pm, "cr88192" <cr88...@NOSPAM .hotmail.comwro te:

"Yunzhong" <gaoyunzh...@gm ail.comwrote in message
>
news:4e2457ef-e23e-41a5-925c-995bd67ddc78@b6 4g2000hsa.googl egroups.com...
>

I don't see C dying out any time soon. The problem with automatic
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.

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

Looking at the past is always easy.
Prophecy proves more difficult.

[Bartc]

Re: Garbage collection


"Eric Sosman" <Eric.Sosman@su n.comwrote in message
news:1209149152 .181452@news1nw k...

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]

Re: Garbage collection


"jacob navia" <jacob@nospam.c omwrote 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.

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]

Re: Garbage collection

>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

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?

[lawrence.jones@siemens.com]

Re: Garbage collection

Paul Hsieh <websnarf@gmail .comwrote:

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

Re: Garbage collection

In article <Z%tQj.15440$yD 2.11636@text.ne ws.virginmedia. com>
Bartc <bc@freeuk.comw rote:

>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 "reachabili ty 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_cont aining() become complicated):

void __scan(TABLE_EN TRY *);
TABLE_ENTRY *__find_entry_c ontaining(POINT ER_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_co ntaining(p)) != NULL)
__scan(e);
for (e in all table entries)
if (!e->ref)
__internal_free (e);
}

void __scan(TABLE_EN TRY *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_co ntaining(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]

Re: Garbage collection

On Apr 25, 5:01 pm, lawrence.jo...@ siemens.com wrote:

Paul Hsieh <websn...@gmail .comwrote:

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.

--
Paul Hsieh

http://www.pobox.com/~qed/

http://bstring.sf.net/

[Richard Heathfield]

Re: Garbage collection

jacob navia said:

<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 misrepresentati on, 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 misrepresentati on).

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]

Re: Garbage collection


"user923005 " <dcorbit@connx. comwrote in message
news:e76d9c78-ad7c-44d8-896c-ba95d0dd5b16@l6 4g2000hse.googl egroups.com...

>On Apr 25, 3:34 pm, "cr88192" <cr88...@NOSPAM .hotmail.comwro te:

>"Yunzhong" <gaoyunzh...@gm ail.comwrote 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).