S
Simon Biber
Kenny said:
Well, 2+2 is not an lvalue, so you can't assign 4 to it. ;-)
Well, 2+2 is not an lvalue, so you can't assign 4 to it. ;-)
P
Paul Connolly
Keith Thompson said:
relatively long and unpredictable pauses are unaccceptable for some
aplications (e.g. trading systems, any time-critical control:
air-traffic-control, nuclear-power-station, DSP, video) Traditional GC
systems have delays in stop-and-copy garbage collection and, even modern
generational scavenging GC has delays. (BTW certain modern object oriented
languages have claimed garbage collection to be part of OO - garbage
collection was invented by the pure functional programing languages)
in C garbage collection is done through the free function - the problems
with the misuse of free are that a programmer can forget to free memory (a
"memory leak") or can free memory that is still being used.
A
Al Balmer
Neither did I.
If so, IMO, he failed. Unless you consider that refraining from
advertising his own product was such an effort ;-)
J
jmcgill
Paul said:
So the assignment-free model is really a myth?
S
SM Ryan
# Well, this is NON-STANDARD. As far as C is concerned, a subtracting
# one from the start of an object is undefined behavior.
The Boehm-Demers collector does not expect assistance
from the compiler or runtime system and so depend
writing programs which are restricted from the full power
of C (standard or other).
Some programs dedicated to the efficiency goddess Dierdre
(who shares an apartment with the software engineering
goddess Eris) will crash and burn spectacularly with a
Boehm-Demers collector. Luckily the restrictions on the
language are easy, reasonable, and drive program development
towards more comprehensible code. Your kilometrage may vary.
Otherwise most of the horror stories of GC are false.
I guess if you're dealing 65KB 8bit single bit CPU
running embedded toaster or ICBM code, GC would be
a mismatch, but I don't write that kind of code anymore.
At least not since that incident in northern Ukraine.
I realized on one project roughly a third of the code
was spent solely on tracking live pointers and collecting
complex data storage. I switched to B-D GC and haven't
looked back.
# one from the start of an object is undefined behavior.
The Boehm-Demers collector does not expect assistance
from the compiler or runtime system and so depend
writing programs which are restricted from the full power
of C (standard or other).
Some programs dedicated to the efficiency goddess Dierdre
(who shares an apartment with the software engineering
goddess Eris) will crash and burn spectacularly with a
Boehm-Demers collector. Luckily the restrictions on the
language are easy, reasonable, and drive program development
towards more comprehensible code. Your kilometrage may vary.
Otherwise most of the horror stories of GC are false.
I guess if you're dealing 65KB 8bit single bit CPU
running embedded toaster or ICBM code, GC would be
a mismatch, but I don't write that kind of code anymore.
At least not since that incident in northern Ukraine.
I realized on one project roughly a third of the code
was spent solely on tracking live pointers and collecting
complex data storage. I switched to B-D GC and haven't
looked back.
C
Chris Dollin
Paul said:
I believe Lisp had destructive update when it acquired GC, but I
could be wrong.
C
Chris Dollin
jmcgill said:
The /languages/ don't have assignment. The /implementation/ may use
it underneath.
C
CBFalconer
Chris said:
I believe Lisp always had GC. Some implementations may not have.
--
Some informative links:
< <http://www.geocities.com/nnqweb/>
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/>
R
Richard Tobin
SM Ryan said:
But if you're running a Lisp interpreter on that hardware (or even
with 32KB), garbage collection is (or was) quite practical. Probably
not written in C though.
-- Richard
R
Richard Tobin
[/QUOTE]
Where does assignment come into it? Memory can be allocated and
become garbage without any assignments.
-- Richard
C
Chris Dollin
CBFalconer said:
So a quick Google got me http://www.iwriteiam.nl/HaCAR_CDR.html,
from which I extract:
Email from Steve Russell
I wrote the first implimenation of a LISP interpreter on the IBM 704
at MIT in early in 1959. I hand-compiled John McCarthy's "Universal
LISP Function".
and
As the 704 has 36 bit words, there were 6 bits in the list nodes
that were not used. Our initial implimentation did not use them at
all, but the first garbage collector, comissioned in the summer of 1959,
used some of them as flags.
which I read as saying the the first implementation had no GC, but
that it was added very shortly afterwards. However, my googlefu is
not sufficient to determine whether Lisp started with set, setcar,
and setcdr or not. If it did, destructive assignment in Lisp preceeded
garbage collection, and hence GC wasn't "invented by the pure functional
programing languages": otherwise, it was.
Further discussion best done off-list, I think. If someone
finds a link for a sufficiently early description of Lisp, I'd
be grateful.
S
sjdevnull
Paul said:
_Some_ traditional GC systems have noticeable delays (e.g mark-sweep
and copy collect). Reference counting has a long tradition and can be
done with real-time guarantees.
More recently, things like Treadmill and Bacon's algorithm offer more
sophisticated real-time GC.
Apropos to the original post, Boehm offers incremental collection to
try to reduce latencies; that's quite nice for interactive
applications, but it's not a real-time solution.
C
Chris Dollin
Bearing in mind that when the last reference to eg a long linked list
is lost, there will be O(length) work done as each dying reference
decrements to 0 and frees the next item.
Not to disparage reference counting, just as a note that no technique
is without its gotchas.
(Also there are delays and DELAYS; I remember the contrast between
two different common lisps on the same hardware: the configuations
of these were such that one would moderately often pause for about
a tenth of a second, just noticable while editing, while the other
would pause much left often, but for about 90seconds at a time.
I strongly suspect that its heap size exceeded the ram size and
that it fell foul of frashing. I mean thrashing. Too long ago to
find out now.)
W
Walter Roberson
Can you? I'm not completely awake yet, but I can't seem to find
a justification for that in C89.
Aliasing via a union: C89 says that it is only defined if the
two elements are part of a common prefix of identical element types.
Type punning via a pointer cast: C89 talks about casting pointers
to and from other types and the circumstances under which the
double-converted result will compare the same as the original.
It does say that when casting pointer types, that the new
pointer might not be valid if the new type pointed to has a
stricter alignment. As char has the least strict alignment
and unsigned char is promised to have the same alignment as
char, that clause could potentially be construed as implying
that the cast pointer to unsigned char would be valid: but
if one takes that interpretation, then the implication would
be that casting a pointer to double into a pointer to short int
into a pointer to short int is going to produce valid results
because short int has alignment requirements no stricter than double.
Any pointer may be converted to pointer to void, and pointer
to void must (in C89) have the same alignment and representation
as pointer to char, but as per the above, it doesn't follow that
the chars (or unsigned chars) are meaningfully accessible.
I seem to recall that unsigned char shall have no padding and
no trap states (but that that is not promised for char or signed char),
so doing the cast to pointer to unsigned char and pulling out the
unsigned char elements is not going to fault -- but is it promised
that the unsigned char values pulled out must be the same as the
bytes of the original pointer representation? Perhaps that is the
logical implication through a good sequence of reasoning, but is
there chapter & verse that ensures that it is so?
T
Thomas J. Gritzan
Frederick said:
Because variables/pointers might be stored in registers. You have to check
the registers of the machine to be sure, that you don't forget any pointer.
This can't be done fully-portable.
[snip malloc-replacement that frees memory at exit]
That is no garbage collector.
Guess a normal C programm that works as a web, mail or file server, that
runs 24 hours 365 days a year. This programm will never exit unless some
administrator thinks that it's time to reboot the machine.
Sooner or later the programm will crash since it owns all memory.
R
Richard Tobin
Frederick Gotham said:
Well yes, but the idea is to free it in time for it to be used by other
malloc()s in the same program!
Something like your code can be used effectively in some cases:
you can record all the memory allocated for some purpose, and
free it when that purpose is complete.
-- Richard
G
gw7rib
jacob said:
It sounds as though you could have the answer to a question of mine. If
people used to store pointers in the extra bytes, but don't do that any
more, what do they do now?
My situation is that I want to find out, when the user does something
to a window, which object is associated with that window. See my post
"Finding the "owner" of a window" in
comp.os.ms-windows.programmer.win32 for more background.
Of course, my question is off-topic on clc, perhaps you might consider
replying to the above post?
Thanks in advance.
Paul.
R
Richard Heathfield
(e-mail address removed) said:
We store pointers in the extra bytes.
Just because Jacob Navia says something, that don't necessarily make it so.
We store pointers in the extra bytes.
Just because Jacob Navia says something, that don't necessarily make it so.
B
Bart
A lot of things in Windows are done by passing pointers to APIs (even
casting them to integers sometimes) and getting them back later through
callbacks. Obviously, the program doesn't hold those pointers in the
mean time. For such uses this GC is quite limiting.
Regards,
Bart.
J
jacob navia
Bart said:
Note that if the APIs are part of some DLLs the GC will see them anyway.
Casts to integers do not affect the GC at all.