Re: Exception Misconceptions: Exceptions are for unrecoverable errors.
In article <hguelj$k49$1@news.albasani.net>, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
Kaz Kylheku wrote:
On 2009-12-23, Branimir Maksimovic <bmaxa@hotmail.com> wrote:
tanix wrote:
In article <hgskgk$kc2$1@news.albasani.net>, Vladimir Jovic
<vladaspams@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
Is not.
Hm, explain to me how can any thread, access or change any pointer in
memory without lock while gc is collecting....
There is no way for gc to collect without stopping all threads
without locking.... because gc is just another thread(s) in itself...
To me, you are talking a kernel moder device driver talk.
You are saying things that may or may not happen in THEORY,
without considering the overall applicability of some concept
to the overall program performance, feature set, ease of use,
and on and on and on.
To tell you the truth, about the ONLY things I care about
as far as memory management goes is how much headache does
it produce for me for managing it and whether it works or not.
YOU can fiddle with those bits all you want.
Does not matter to me even a bit. I have no plans to rewrite
GC and can not even conceive such an idea.
All I know IT WORKS. And I can do it number of times faster
than you. And it still going to work. I don't even WANT
to hear about memory management issues as being ANY kind
of problem. We are WAY past that stage in the game.
Simple as that.
Now we have to solve the issues of having non dynamically
scoped languages being as portable as modern dynamically
scoped languages, such Php, the premiere language of web,
Javascript, Python, Ruby, SQL, and even HTML.
What seems to apply here is the issue of not seeing the
forest for the trees, more than anything else.
in combination with threads....it is slow, complex and inefficient...
Religious belief.
Of course. GC is complex program that has only one purpose.
To let programmer not write free(p), but programmer
still has to write close(fd).
What's the purpose of that?
Because close is a LOGICAL operation that can not be performed
automatically unless the program terminates.
And free() is not, just as GC proves beyond all doubt.
Recursion is not directly connected to the need for garbage collection;
this is some kind of strange misconception.
GC without threads, but processes and shared memory instead, is ok on
multiprocessor systems...
GC is very efficient from an SMP point of view, because it allows
for immutable objects to be truly immutable, over most of their
lifetime. No book-keeping operations have to be performed on objects
that are just passed around throughout the program (such as bumping
refcounts up and down).
Refcounts are negligible in comparison to what gc is doing.
GC cannot be efficient since it cannot access program
memory while program is working....ad it doesn;t know what program is
doing... therefore GC can perform well only if it collect
when absolutely necessary. And when it had to collect performance
became catastrophic...
Sorry. But this is totally unproductive.
Cya.
No storage reclamation strategy is free of overhead. Even if your program
correctly manages memory by itself with explicit new and delete, there is a
cost.
Manual memory deallocation is simple, fast and efficient. Nothing
so complex like GC.
Cost of new and delete is nothing in comparison to GC.
Moreover, a poorly implemented heap allocator (like virtually
every default malloc implementation out there in the real world)
is an SMP performance killer.
Yeah right. And GC thread is black magic , right?
Like malloc and new, GC can be badly implemented in a way that kills SMP
performance. So can any aspect a programming language implementation,
including
the compiler.
GC cannot be implemented efficiently since it has to mess with
memory...while other threads are working.
Add that compacting collector which have to update all references
in program and some copy/pasting... that can be optimised... to be
faster than new/delete , yeah right ;)
That may be so, but GC does not require a virtual machine. GC has been used
for
five decades, with natively compiled code, starting in the late 1950's on IBM
704 mainframes, as part of the Lisp run-time support.
I used GC with C++...
I think java is designed in such way that it will still be slow in
comparison to other compiled languages...if it is compiled
language.
Unfortunately, that is wishful thinking. Natively compiled Java has very
little
disadvantage compared to C and C++. (Mainly in areas of doing low-level
things
with memory, or directly interfacing with the ``bare iron''; the sorts
of things that are poorly supported in Java).
I don;t want to discuss this, but it is obvious that nothing in java is
designed with performance in mind. Quite opposite....
Greets
--
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.