SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University of
Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz 72 3357
Sebastian Nibisz a écrit :
SGCL is precise, parallel garbage collection library for C++ (at this
time for Windows 32/64 only). SGCL is free software published under
University of Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
If you need garbage collection you should try D language.
* Sebastian Nibisz peremptorily fired off this memo:
SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only).
Ridiculous.
SGCL is free software published under University of
Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
--
When the PC was launched, people knew it was important.
-- Bill Gates
If you need garbage collection you should try D language.
The D language doesn't have the parallel garbage collector.
Regards
Sebastian Nibisz
On Feb 28, 8:09 am, "Sebastian Nibisz" <EB...@poczta.onet.plwrote:
SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University of
Illinois/NCSA Open Source License.
Get it at:http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
Garbage collection is for lazy rich folks who can't be bothered to
take out their own trash.
Garbage collection is for lazy rich folks who can't be bothered to
take out their own trash.
It's funny.
Garbage collection is for lazy rich folks who can't be bothered to
take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
node* root = new node;
node* n = root;
for (int x = 0; x < 10; ++x)
{
n = n->next = new node;
n->next = 0;
}
n=root;
while(n){
root=n;
n=n->next;
delete root;
}
is that 6 lines too much for you?
if your reply is yes then use a GC.
Be happy.
"Sebastian Nibisz" <EB***@poczta.onet.plha scritto nel messaggio
news:fq**********@inews.gazeta.pl...
>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
On 2008-02-28 17:26, Sebastian Nibisz wrote:
>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
A recursive function?
--
Erik Wikström
Sebastian Nibisz wrote:
>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
std::list<>
or boost::intrusive::list<>
or struct node { smart_pointer<nodenext; };
or explicit destruction as Alberto described
or allocation from a pool which is all deallocated together
or garbage collection.
All have their advantages and disadvantages. Personally I'm happy with
std::list 99% of the time. I'm actually quite curious to know what sort
of applications or users use garbage collection in C++, but I fear that
it's the sort of discussion that can deteriorate....
Phil.
Sebastian Nibisz schrieb:
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
struct node
{ // content...
};
std::slist<boost::shared_ptr<node ?
or
struct node
{ boost::shared_ptr<nodenext;
};
or if you look for very high performant solutions try
boost::intrusive_ptr which allows very small memory footprints of your
nodes because no additional heap objects are allocated at all.
In fact the only domain of GC solutions are complex data structures with
many cyclic references and without a parent child relation.
Marcel
or
>
struct node
{ boost::shared_ptr<nodenext;
};
{
for (int x = 0; x < 1000000; ++x)
{
n = n->next = shared_ptr<node>(new node);
}
} // <- STACK OVERFLOW
rgds
Sebastian Nibisz
Erik Wikström schrieb:
On 2008-02-28 17:26, Sebastian Nibisz wrote:
>>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
struct node { node* next; };
node* root = new node; node* n = root;
for (int x = 0; x < 1000000; ++x) { n = n->next = new node; }
How to release memory?
A recursive function?
Stack overflow?
--
Thomas http://www.netmeister.org/news/learn2quote.html
To iterate is human, to recurse divine.
-L. Peter Deutsch
Sebastian Nibisz wrote:
>or
struct node { boost::shared_ptr<nodenext; };
{
for (int x = 0; x < 1000000; ++x)
{
n = n->next = shared_ptr<node>(new node);
}
} // <- STACK OVERFLOW
Why?
Sebastian Nibisz wrote:
>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
struct node
{
node* next;
};
node* root = new node;
node* n = root;
for (int x = 0; x < 1000000; ++x)
{
n = n->next = new node;
}
How to release memory?
It's hard to guess why you would allocate nodes that way in the first place.
>{
> for (int x = 0; x < 1000000; ++x) { n = n->next = shared_ptr<node>(new node); } } // <- STACK OVERFLOW
Why?
{
shared_ptr<noderoot(new node);
shared_ptr<noden(root);
for (int x = 0; x < 1000000; ++x)
{
n = n->next = shared_ptr<node>(new node);
}
} // <- recursive destruction (root)
rgds
Sebastian Nibisz
for (int x = 0; x < 10; ++x)
{
n = n->next = new node;
n->next = 0;
}
n=root;
while(n){
root=n;
n=n->next;
delete root;
}
Ok. What if there is a cyclical list?
node* root = new node;
node* n = root;
node* r_n;
int r = rand() % 10;
for (int x = 0; x < 10; ++x)
{
n = n->next = new node;
if (x == r)
{
r_n = n;
}
}
n->next = r_n;
>struct node
>{ node* next; };
node* root = new node; node* n = root;
for (int x = 0; x < 1000000; ++x) { n = n->next = new node; }
How to release memory?
It's hard to guess why you would allocate nodes that way in the first
place.
The parent must know the child.
rgds
Sebastian Nibisz
On Feb 28, 7:25 pm, Phil Endecott <spam_from_usenet_0...@chezphil.org>
wrote:
Sebastian Nibisz wrote:
or
struct node
{ boost::shared_ptr<nodenext;
};
{
for (int x = 0; x < 1000000; ++x)
{
n = n->next = shared_ptr<node>(new node);
}
} // <- STACK OVERFLOW
Why?
You're kidding us, right?
Eric was obviously being facious with his suggestion, since it
obviously wouldn't work; I can't imagine anyone not spotting the
problem immediately. The trick about shared_ptr, here, of
course, is that you don't see the recursion, so you may not
realize that you have the same problem until someone explicitly
asks what will happen.
It's really pretty rare that you can recurse 1000000 times
without the stack overflowing.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sebastian Nibisz wrote:
SGCL is precise, parallel garbage collection library for C++ (at this
time for Windows 32/64 only). SGCL is free software published under
University of Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
Sounds like interesting stuff for anyone who wants to use GC in his/her
applications.
The thread shouldn't turn out to the flame "Do we need garbage
collection"? Anyone that can afford it in his/her applications and wants
to, he/she may use it.
Sebastian Nibisz wrote:
SGCL is precise, parallel garbage collection library for C++ (at this
time for Windows 32/64 only). SGCL is free software published under
University of Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
Regards
Sebastian Nibisz
Sounds like interesting stuff for anyone who wants to use GC in his/her
applications.
The thread shouldn't turn out to the flame "Do we need garbage
collection"? Anyone that can afford it in his/her applications and wants
to, he/she may use it.
James Kanze wrote:
On Feb 28, 7:25 pm, Phil Endecott <spam_from_usenet_0...@chezphil.org>
wrote:
>Sebastian Nibisz wrote:
>>>or
>>>struct node { boost::shared_ptr<nodenext; };
>>{ for (int x = 0; x < 1000000; ++x) { n = n->next = shared_ptr<node>(new node); } } // <- STACK OVERFLOW
>Why?
You're kidding us, right?
James, that's pretty rude. I know this is usenet but I'd really
appreciate if if you could moderate the way you express yourself. I am
not "kidding you" when I say that I did not spot this problem, which is
why I asked "Why?". I have learnt something new and interesting this
evening. Why you had to chime in with that patronising phrase is beyond me.
Goodbye.
Sebastian Nibisz writes:
>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
It's funny.
It's true. If you do not have the skills and the know-how to keep track of
your own objects, and manage their lifetime, you have no business writing
mission-critical, business software.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHx1dux9p3GYHlUOIRAsG0AJ9jyQycVNKccijiGxu+wt SXfYZ3pQCfYtcN
eALnun9Sn1DJK+2aUAlLpt0=
=jUjy
-----END PGP SIGNATURE-----
Sebastian Nibisz writes:
>for (int x = 0; x < 10; ++x) { n = n->next = new node; n->next = 0; }
n=root; while(n){ root=n; n=n->next; delete root; }
Ok. What if there is a cyclical list?
Use your brain, and add two lines of code to the above fragment, making it
work for cyclical lists.
No, I'm not going to show you how to do it. I'm not sure you'll be able to
understand it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHx1f8x9p3GYHlUOIRAgtHAJ9XsfYsIvZ4pQ8W4t4Kx6 DXxkTDOwCeLBAg
JXRwFrr2SpQBU4RR0SSAWjU=
=vSvG
-----END PGP SIGNATURE-----
I am impressed by your intelligence.
Sebastian Nibisz writes:
I am impressed by your intelligence.
You should be. You can't even manage the task of quoting the message you're
replying to, so that others actually may have a hint as to what in blazes
you're yammering about.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHx2ikx9p3GYHlUOIRAls5AJ9tENSCTFk2gJcMhcw6xS blXxn9PACfUcYj
MH1+Wpay/btH5+bKpq6HVG8=
=JOuP
-----END PGP SIGNATURE-----
Sebastian Nibisz wrote:
>>struct node { node* next; };
node* root = new node; node* n = root;
for (int x = 0; x < 1000000; ++x) { n = n->next = new node; }
How to release memory?
It's hard to guess why you would allocate nodes that way in the first place.
The parent must know the child.
Sorry, I meant why not use a standard container to manage the nodes'
lifetimes? The slist mentioned elsewhere on this thread was a
reasonable suggestion, if std::list is too heavy.
Alf P. Steinbach wrote:
* James Kanze:
>On Feb 28, 7:25 pm, Phil Endecott <spam_from_usenet_0...@chezphil.org> wrote:
>>Sebastian Nibisz wrote: or
>>>>struct node { boost::shared_ptr<nodenext; };
>>>{ for (int x = 0; x < 1000000; ++x) { n = n->next = shared_ptr<node>(new node); } } // <- STACK OVERFLOW
>>Why?
You're kidding us, right?
....
>> It's really pretty rare that you can recurse 1000000 times without the stack overflowing.
Huh?
I'm not sure it's obvious until you're been looking at it for a few
minutes, but given a program like the following:
#include <tr1/memory>
using std::tr1::shared_ptr;
struct node {
shared_ptr<nodenext;
};
int main() {
shared_ptr<noderoot(new node);
shared_ptr<noden(root);
for (int x = 0; x < 1000000; ++x) {
n = n->next = shared_ptr<node>(new node);
}
}
When the "root" shared_ptr goes out of scope, the first node's reference
count goes to zero. root's destructor therefore deletes the first node,
causing the destructor of root->next to be invoked. That destructor
sees the reference count of the second node become zero, and so deletes
the second node, causing root->next->next to be invoked. And so on...
A better approach, IMHO, would be to let a factory allocate the nodes,
preferably as elements of a std::list<node>. The factory's destructor
(the list's, really) can make sure the memory is freed.
On Feb 29, 1:53 am, Sam <s...@email-scan.comwrote:
Sebastian Nibisz writes:
Garbage collection is for lazy rich folks who can't be
bothered to take out their own trash.
It's funny.
It's true. If you do not have the skills and the know-how to
keep track of your own objects, and manage their lifetime, you
have no business writing mission-critical, business software.
And if you intentionally reject the use of a labor saving
device, and do something by hand which can easily be automated,
you're being professionally irresponsible.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 28 Feb, 14:49, Linonut <lino...@bollsouth.nutwrote:
* Sebastian Nibisz peremptorily fired off this memo:
SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only).
Ridiculous.
why?
<snip>
--
Nick Keighley
On Feb 29, 1:08 am, Phil Endecott <spam_from_usenet_0...@chezphil.org>
wrote:
James Kanze wrote:
On Feb 28, 7:25 pm, Phil Endecott <spam_from_usenet_0...@chezphil.org>
wrote:
Sebastian Nibisz wrote: or
>>struct node { boost::shared_ptr<nodenext; };
>{ for (int x = 0; x < 1000000; ++x) { n = n->next = shared_ptr<node>(new node); } } // <- STACK OVERFLOW
Why?
You're kidding us, right?
James, that's pretty rude.
I'm sorry, but it's frustrating. Somewhat upthread, someone
said "recursion", doubtlessly ironically, since I do presume
that everyone would realize thatexplicitly recursing 1000000
times was a bad idea. Given the fact that the use of shared_ptr
was suggested in that context, it seems obviously just an
extention of the irony to me---let's hide the recursion.
Without this context, frankly, I don't think many people would
spot the problem in code review. Given the context, however, I
do find it very surprising that people whom I know to be
competent do not see the problem immediately. It makes the
irony somewhat ineffective (although it does strengthen the
argument against unthinking use of shared_ptr). Which is, of
course, frustrating to those of us who are trying to use it.
I know this is usenet but I'd really appreciate if if you
could moderate the way you express yourself. I am not
"kidding you" when I say that I did not spot this problem,
which is why I asked "Why?". I have learnt something new and
interesting this evening. Why you had to chime in with that
patronising phrase is beyond me.
Because people not realizing the problem, in context, spoils the
rhetorical effect of the irony. Sorry. But as soon as Erik
mentionned recursion, it occured to me that I could "hide" it in
a shared_ptr, and that since shared_ptr was often suggested as
an alternative to garbage collection. Then you and Alf go and
spoil the effect (and I know both of you to be extremely
competent programmers) by missing the irony.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
In message <co*****************************@commodore.email-scan.com>,
Sam <sa*@email-scan.comwrites
>Sebastian Nibisz writes:
>>Garbage collection is for lazy rich folks who can't be bothered to take out their own trash.
It's funny.
It's true. If you do not have the skills and the know-how to keep track of your own objects, and manage their lifetime,
.... or if you think garbage collection is about lifetime management ...
>you have no business writing mission-critical, business software.
--
Richard Herring
On Feb 29, 6:27 pm, "Alf P. Steinbach" <al...@start.nowrote:
* James Kanze:
Given that someone had already said "stack
overflow", I'm rather surprised that Alf missed it---he doesn't
usually miss these sort of things.
I think we rely much more on simple pattern matching (and
hence expectations and previous experience) than reasoning.
Not sure if you've read David Brin's uplift trilogy, but
there's this scene where two guys cross the wilderness and one
of them plants a lot of false evidence to convince the other
there's someone shadowing them. However, the other guy
doesn't even notice all this fake evidence, because it's so
bad, so fake, so atypical, that it doesn't even reach his
higher cognitive functions for consideration... It's
automatically filtered out, because it doesn't make sense even
at the lowest level of external input processing.
I'm not familiar with it, but yes. Context certainly plays a
large role; we normally only see things we're looking for, and
what we look for depends to a large degree on what we expect to
find.
I'll admit that without the comment about "recursion"
immediately up-thread, I probably wouldn't have spotted it
either. However, that word triggered something in my mind, a
comment by Hans Boehm, I think, to the effect that manual memory
management can create the same pauses people complain about in
garbage collection. With a long list or a complex tree being
his example, where destruction of the root triggers *recursive*
destruction of hundreds of thousands of elements. Without
that... (In other words, I'd already had the case explained to
me by a master.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ian Collins wrote:
True, but there's plenty of embedded platforms with POSIX support where
garbage collection, even if available, would be acceptable.
Make that "*not* acceptable!
--
Ian Collins.
Sam wrote:
James Kanze writes:
>On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote:
>>Richard Herring writes: In message <cone.1204246382.29097.21741....@commodore.email-scan.com>, Sam <s...@email-scan.comwrites
>>Let me know when you figure out why, in Java, you have to throw all these try/catch blocks around, every time you need to deal with files or sockets,
Because Java doesn't have local objects or destructors. Which
Java most certainly has destructors. See java.lang.Object.finalize().
But that's not an automatic destructor in the C++ sense, is it?
--
Ian Collins.
Ian Collins writes:
Sam wrote:
>James Kanze writes:
>>On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: Richard Herring writes: In message <cone.1204246382.29097.21741....@commodore.email-scan.com>, Sam <s...@email-scan.comwrites
Let me know when you figure out why, in Java, you have to throw all these try/catch blocks around, every time you need to deal with files or sockets,
Because Java doesn't have local objects or destructors. Which
Java most certainly has destructors. See java.lang.Object.finalize().
But that's not an automatic destructor in the C++ sense, is it?
It is a destructor in the C++ sense as in "gets invoked before the object's
memory is released".
That's precisely the point I am making. Garbage collection's only benefit is
to clean up your objects when you can't keep track of their lifetime, and
must rely on the garbage collector to destroy the objects when they no
longer have any strong references. Because if you do have the discipline to
keep track of your objects, and destroy them when they're no longer needed,
you don't need any fscking garbage collector.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHyNPKx9p3GYHlUOIRAunEAJwMc6Pxo/9NJ2Z0MNbhEbTAcbRrhACfW/B5
kdEi/tRJSOkWIHk0gIhJtxo=
=yFza
-----END PGP SIGNATURE-----
On Fri, 29 Feb 2008 21:55:54 -0600, Sam wrote:
That's precisely the point I am making. Garbage collection's only
benefit is to clean up your objects when you can't keep track of their
lifetime, and must rely on the garbage collector to destroy the objects
when they no longer have any strong references. Because if you do have
the discipline to keep track of your objects, and destroy them when
they're no longer needed, you don't need any fscking garbage collector.
But if you don't particularly care when objects are deleted (which, when
the only resource an object uses is memory, you may be right not to care
about), then with a GC you don't need the discipline to keep track of
these objects. Which is good, because my discipline, at any rate, is
finite, and I would like to preserve it for those cases where it matters,
not those cases where it doesn't matter.
Sam wrote:
Ian Collins writes:
>Sam wrote:
>>James Kanze writes:
On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: Richard Herring writes: In message <cone.1204246382.29097.21741....@commodore.emai l-scan.com>, Sam <s...@email-scan.comwrites
Let me know when you figure out why, in Java, you have to throw all these try/catch blocks around, every time you need to deal with files or sockets,
Because Java doesn't have local objects or destructors. Which
Java most certainly has destructors. See java.lang.Object.finalize().
But that's not an automatic destructor in the C++ sense, is it?
It is a destructor in the C++ sense as in "gets invoked before the
object's memory is released".
Now, that is definitely _not_ a destructor in the C++ sense: according to
[3.8/4] it is possible to release or reuse memory without the destructor
getting invoked before.
That's precisely the point I am making. Garbage collection's only benefit
is to clean up your objects when you can't keep track of their lifetime,
and must rely on the garbage collector to destroy the objects when they no
longer have any strong references. [snip]
Are you sure that garbage collectors for C++ _destroy_ objects that become
unreachable? I was under the impression that they only reclaim the memory
and do not invoke the destructor.
Best
Kai-Uwe Bux
Ian Collins wrote:
Ian Collins wrote:
>True, but there's plenty of embedded platforms with POSIX support where garbage collection, even if available, would be acceptable.
Make that "*not* acceptable!
As all computers (from small embedded devices to large mainframes) are
getting more powerful along with their accompanying facilities, the
abstraction in programming will be increasing. Now we have those CLI
compliant GC frameworks (.NET, Mono etc), and I am pretty sure GC will
be common place sometime in the near future. Also we will see more
abstraction facilities, and less trade offs between space and speed. The
same applies for storage medium. For example consider mp3/ogg vs flac.
Now we have "mp3 players" with storage >1 GB.
This flame in this thread, reminds me other silly flames between C and
C++ advocates, with the C ones insisting that they can do whatever they
need without object oriented programming, templates etc.
Personally I think the near future will be with more abstraction (like
more templates, GC) and with less low-level facilities, since space and
run-time will have less importance, because of the more and more
powerful systems.
Kai-Uwe Bux wrote:
Sam wrote:
>Ian Collins writes:
>>Sam wrote: James Kanze writes:
On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: >Richard Herring writes: >>In message >><cone.1204246382.29097.21741....@commodore.e mail-scan.com>, Sam >><s...@email-scan.comwrites >Let me know when you figure out why, in Java, you have to >throw all these try/catch blocks around, every time you need >to deal with files or sockets, Because Java doesn't have local objects or destructors. Which Java most certainly has destructors. See java.lang.Object.finalize().
That's not a destructor in the C++ sense, it's a finalizer.
>>But that's not an automatic destructor in the C++ sense, is it?
It is a destructor in the C++ sense as in "gets invoked before the object's memory is released".
Now, that is definitely _not_ a destructor in the C++ sense: according to
[3.8/4] it is possible to release or reuse memory without the destructor
getting invoked before.
Or, for that matter, to invoke the destructor without releasing the
memory (as std::vector does on each call to pop_back).
>That's precisely the point I am making. Garbage collection's only benefit is to clean up your objects when you can't keep track of their lifetime, and must rely on the garbage collector to destroy the objects when they no longer have any strong references. [snip]
Are you sure that garbage collectors for C++ _destroy_ objects that become
unreachable? I was under the impression that they only reclaim the memory
and do not invoke the destructor.
I am not familiar with the Boehm collector; ref-counted GC (e.g.
shared_ptr) does invoke the destructor. In general, though, I believe
you are correct: The two ideas of destruction and collection are
distinct and separable.
"Sebastian Nibisz" <EB***@poczta.onet.plwrote in message
news:fq**********@inews.gazeta.pl...
SGCL is precise, parallel garbage collection library for C++ (at this time
for Windows 32/64 only). SGCL is free software published under University
of Illinois/NCSA Open Source License.
Get it at: http://sourceforge.net/projects/sgcl/
How does this compare against a virtually zero-overhead PDR algorithm?
On 1 mar, 04:55, Sam <s...@email-scan.comwrote:
Ian Collins writes:
Sam wrote:
James Kanze writes:
>On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: Richard Herring writes: In message <cone.1204246382.29097.21741....@commodore.email-scan.com>, Sam <s...@email-scan.comwrites
>>Let me know when you figure out why, in Java, you have to throw all these try/catch blocks around, every time you need to deal with files or sockets,
>Because Java doesn't have local objects or destructors. Which
Java most certainly has destructors. See
java.lang.Object.finalize().
But that's not an automatic destructor in the C++ sense, is it?
It has nothing to do with a destructor in the C++ sense, and
serves a completely different role.
It is a destructor in the C++ sense as in "gets invoked before
the object's memory is released".
That's not what a destructor is in C++ (and not necessarily
true---typically, it's not true for local variables, nor for
static objects, nor for member variables, for example). A
destructor in C++ is a function which is called at a specific
time, and "deconstructs" an object into raw memory.
If the destructor is called as part of a delete expression, then
operator delete() will be called immediately afterwards, which
may or may not immediately free the memory. (Typically, it will
immediately free the memory, except in some cases where the
delete is called in a different thread than the corresponding
new.)
That's precisely the point I am making.
The problem is that the point you're making is simply false.
Garbage collection's only benefit is to clean up your objects
when you can't keep track of their lifetime, and must rely on
the garbage collector to destroy the objects when they no
longer have any strong references.
That's the first time I've heard that. No one arguing in favor
of garbage collection has presented such an argument.
Rather than inventing idiocies, and then proving them false, you
should try addressing what people are really saying.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 1 mar, 06:14, Kai-Uwe Bux <jkherci...@gmx.netwrote:
[...]
Are you sure that garbage collectors for C++ _destroy_ objects
that become unreachable? I was under the impression that they
only reclaim the memory and do not invoke the destructor.
That's because you actually know what you're talking about, and
having just imagined some strawman to argue against.
Destructors have no relationship with Java's finalize method.
The closest concept to destructors in Java is a finally block.
There are a few special cases where a finally block works better
than destructors (closing files is an obvious example, where
only the user can know what the appropriate behavior is in case
of an error), but they are IMHO very much the exception---for
something between 90% and 99% of the time, destructors are
preferable.
In most cases (there are a few exceptions), finalization is
really only usable for error detection. (I've written large
applications in Java, and have never used it.)
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze writes:
On 1 mar, 04:58, Sam <s...@email-scan.comwrote:
><Splorf>
>That actually happened at day job, last week. A tick data app ran out of memory and crashed, because it kept chewing on the exchange's tick feed, and had no spare cycles for the Java VM to run the garbage collector, and release memory held my objects that were no longer in use.
Unless you've modified the JVM in some way, that simply cannot
happen. When Java runs out of memory, it automatically triggers
garbage collection. It sounds more like your application had a
memory leak. (Note that memory leaks are also possible without
garbage collection. In fact, garbage collection reduces the
risk of memory leaks. Without bringing it down to zero, of
course.)
Don't take my word for it. http://java.sun.com/docs/white/langenv/Simple.doc1.html
# The Java run-time system takes advantage of these idle periods and runs
# the garbage collector in a low priority thread when no other threads are
# competing for CPU cycles.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBHys3kx9p3GYHlUOIRAqqhAJ9Mjwj4/jRtZoxKNDJ3UdfptBRWGQCfRT0Z
DTzRauZZL933CKgmSh3CJ/4=
=TkaR
-----END PGP SIGNATURE-----
James Kanze wrote:
On 1 mar, 04:55, Sam <s...@email-scan.comwrote:
>Ian Collins writes:
>>Sam wrote: James Kanze writes:
>>>>On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: >Richard Herring writes: >>In message <cone.1204246382.29097.21741....@commodore.email-scan.com>, >>Sam <s...@email-scan.comwrites
>>>>>Let me know when you figure out why, in Java, you have to >throw all these try/catch blocks around, every time you need >to deal with files or sockets,
>>>>Because Java doesn't have local objects or destructors. Which
>>>Java most certainly has destructors. See java.lang.Object.finalize().
>>But that's not an automatic destructor in the C++ sense, is it?
It has nothing to do with a destructor in the C++ sense, and
serves a completely different role.
Isn't that what I said?
--
Ian Collins.
On Mar 2, 2:56 pm, Juha Nieminen <nos...@thanks.invalidwrote:
[snip]
There are other less-understood problems with garbage collection which
few people realize.
One such problem is that garbage collection can be quite detrimental
with respect to swapping.
[snip]
I can speak for this; this was especially a problem on Apple's JVM, at
least as of about a year ago, I'm not sure if they've fixed the issues
since. In particular, there was a rather memory-intensive, popular
online game that stored most of it's graphics in system memory, and
when it decided to run the GC it would have to swap in all the pages
-- and it crippled the *entire* system for 30-45 seconds every 10
minutes or so. It was very unacceptable, and made the game virtually
unplayable for nearly all of the Mac users who were trying to play it.
It was a problem that did not happen on non-Apple JVM's. I think the
major problem there was Apple's algorithm for deciding when to run the
garbage collector -- it seemed to only run it when the system was
running low on memory, waiting until the last minute. Unfortunately,
this also meant most of the "garbage" was probably in the page file.
If it had run the garbage collector more frequently, perhaps at
regular intervals, I do not think that issue would have occurred.
Still, in that case, it seemed like more of a specific GC
implementation issue rather than a problem with garbage collection
itself. The problem was unique to Apple's JVM.
Just thought I'd share the memory of that game,
Jason
On 2 mar, 16:55, Sam <s...@email-scan.comwrote:
James Kanze writes:
On 1 mar, 04:58, Sam <s...@email-scan.comwrote:
That actually happened at day job, last week. A tick data app
ran out of memory and crashed, because it kept chewing on the
exchange's tick feed, and had no spare cycles for the Java VM
to run the garbage collector, and release memory held my
objects that were no longer in use.
Unless you've modified the JVM in some way, that simply cannot
happen. When Java runs out of memory, it automatically triggers
garbage collection. It sounds more like your application had a
memory leak. (Note that memory leaks are also possible without
garbage collection. In fact, garbage collection reduces the
risk of memory leaks. Without bringing it down to zero, of
course.)
Don't take my word for it.
http://java.sun.com/docs/white/langenv/Simple.doc1.html
# The Java run-time system takes advantage of these idle periods and runs
# the garbage collector in a low priority thread when no other threads are
# competing for CPU cycles.
In addition to running it when there is no memory available for
a new. That's a simple (and frequently applied) optimization
measure, but it doesn't change the fact that if your application
doesn't leak memory, and doesn't require more than the available
memory, it will not crash because of a lack of memory. In other
words, the scenario that you described isn't possible.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On 2 mar, 19:19, Ian Collins <ian-n...@hotmail.comwrote:
James Kanze wrote:
On 1 mar, 04:55, Sam <s...@email-scan.comwrote:
Ian Collins writes: Sam wrote: James Kanze writes:
>>>On Mar 1, 12:24 am, Sam <s...@email-scan.comwrote: Richard Herring writes: >In message <cone.1204246382.29097.21741....@commodore.email-scan.com>, >Sam <s...@email-scan.comwrites
>>>>Let me know when you figure out why, in Java, you have to throw all these try/catch blocks around, every time you need to deal with files or sockets,
>>>Because Java doesn't have local objects or destructors. Which
>>Java most certainly has destructors. See java.lang.Object.finalize().
>But that's not an automatic destructor in the C++ sense, is it?
It has nothing to do with a destructor in the C++ sense, and
serves a completely different role.
Isn't that what I said?
Yes. I wasn't disagreeing with you. Just trying to say it in
an even stronger way.
--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sam wrote:
James Kanze writes:
[snip]
> Garbage
[snip]
>collection is essential in Java, because all objects must be allocated dynamically, and user defined types can't have value semantics. It's optional in C++, because we do have value semantics. Optional, but it still saves the programmer some unnecessary work.
No, it's not "optional" in C++. It does not exist, at all, in C++. Go look
up the "optional" part of ISO/IEC 14882:2003 that defines whatever you
think "garbage collection" means in the C++ context. I eagerly await the
results of your search.
I don't think that is entirely correct. The C++ standard is worded very
cautiously with regard to new and delete to leave a tremendous amount of
freedom to the implementation. I think, a compliant implementation could
use garbage collection. In particular, I do not know of any language in the
C++ standard that would require the following program to ask the execution
environment for an unbounded amount of memory:
int main ( void ) {
while ( true ) {
new int ( 5 );
}
}
Best
Kai-Uwe Bux This thread has been closed and replies have been disabled. Please start a new discussion. |