Re: Exception Misconceptions: Exceptions are for unrecoverable
errors.
In article <20091225195850.746@gmail.com>, Kaz Kylheku <kkylheku@gmail.com> wrote:
On 2009-12-25, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
James Kanze wrote:
On Dec 23, 11:21 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
tanix wrote:
In article <hgskgk$kc...@news.albasani.net>, Vladimir Jovic
<vladasp...@gmail.com> wrote:
C++ would probably be benefited tremendously if it adopted some
of the central Java concept, such as GC, threads and GUI.
GC is heavy performance killer especially on multiprocessor systems
in combination with threads....it is slow, complex and inefficient...
Obviously, you've never actually measured. A lot depends on the
application, but typically, C++ with garbage collection runs
slightly faster than C++ without garbage collection. Especially
in a multi-threaded envirionment,
How that can possibly be?
How it can be is that surprising truths in the world don't take a pause
so that morons can catch up.
Wow! That looks like a wresting arena!
:--}
GC kills all threads when it has
to collect?
Big news: stopping threads using the scheduler is more efficient than
throwing locks or atomic instructions in their execution path.
Kewl argument.
What's more efficient: pausing a thread once in a long while, or having
it constantly trip over some atomic increment or decrement, possibly
millions of times a second?
Or it can magically sweep through heap,stack,bss
etc and scan without locking all the time or stopping program?
The job of GC is to find and reclaim unreachable objects.
That's what I though. But who knows. May be there is some magic to it.
:--}
When an object becomes unreachable, it stays that way. A program does
not lose a reference to an object, and then magically recover the
reference. Thus, in general, garbage monotonically increases as
computation proceeds.
This means that GC can in fact proceed concurrently with the
application. The only risk is that the program will generate more
garbage while GC is running, which the GC will miss---objects which GC
finds to be reachable became unreachable before it completes.
But that's okay; they will be found next time.
This is hinted at in the ``snapshot mark-and-sweep'' paragraph
in the GC algorithms FAQ.
http://www.iecc.com/gclist/GC-algorithms.html
Explain to me how?
Go study garbage collection. There is lots of literature there.
It's not a small, simple topic.
Manual deallocation does not have to lock at all....
WTF are you stuipd?
Firstly, any comparison between GC and manual deallocation is moronic.
Well, kinda blunt way of putting it, but I'd have to agree.
In order to invoke manual deallocation, the program has to be sure
that the object is about to become unreachable, so that it does
not prematurely delete an object that is still in use. Moreover,
the program has to also ensure that it eventually identifies all objects
that are no longer in use. I.e. by the time it calls the function, the
program has already done exactly the same the job that is done by the
garbage collector: that of identifying garbage.
/Both/ manual deallocation and garbage collection have to recycle
objects somehow; the deallocation part is a subset of what GC does.
(Garbage collectors integrated with C in fact call free on unreachable
objects; so in that case it is obvious that the cost of /just/ the call
to free is lower than the cost of hunting down garbage /and/ calling
free on it!)
The computation of an object lifetime is not cost free, whether it
is done by the program, or farmed off to automatic garbage collection.
Your point about locking is naively wrong, too. Memory allocators which
are actually in widespread use have internal locks to guard against
concurrent acces by multiple processors. Even SMP-scalable allocators
like Hoard have locks. See, the problem is that even if you shunt
allocation requests into thread-local heaps, a piece of memory may be
freed by a different thread from the one which allocated it. Thread A
allocates an object, thread B frees it. So a lock on the heap has to be
acquired to re-insert the block into the free list.
--
Programmer's Goldmine collections:
http://preciseinfo.org
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.