Darren New wrote:
> In a system that actually actively supports GC, 

Oh, and there are actually versions of GC that reference-count objects 
that have external resources in them, and clean them up promptly if you 
don't let the reference escape the scope they're in.  (Actually, isn't 
Java doing this sort of thing now somewhere?)

Looking at Java's GC and concluding that GC sucks is like looking at 
notepad and concluding that text processors suck.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

Darren New wrote:

> Looking at Java's GC and concluding that GC sucks is like looking at 
> notepad and concluding that text processors suck.

OK, *surely* this ought to be quoted somewhere prominent? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Manually closing the file handle when it's not needed anymore is not
> > any better then manual memory management: There's always the danger of
> > a leak. Functions may be exited at unexpected places, etc.

> Of course, all these objections are fairly irrelevant when the OS is 
> actually designed to help the GC system.

  The OS may help the GC system when we are talking about OS resources.
However, it can't help when we are talking about resources within the
program itself. (For the sake of example, let's assume that the program
uses its own "file handles" instead of the ones provided by the system.
It doesn't need to be something related to physical files per se.)

> For example, nobody complains "UNIX signals are bad, because if you 
> don't catch them, your process might have files open when it exits."

  The problem is not leaving file handles open when the program exits.
The problem is opening more and more file handles without closing the
old ones: In most systems at some point the OS will put a limit to this
and refuse to give any more file handles. At this point the program will
malfunction, and finding and solving the cause can be quite difficult.

  Usually this is a sign of a bug: Some code somewhere is "leaking".
Not all unused file handles are being closed.
  However, with GC, where there's delayed object destruction, it might
not be a bug per se, but a consequence of GC.

> No, the OS closes the files for you.

  It can't close them if it sees that they are in use: Some live objects
are holding the file handles (because these objects have not been
properly destroyed).

> In a system that actually actively supports GC, a program trying to 
> access a file handle that someone else has open (and locked) will cause 
> a GC in that program to finalize those resources, freeing up the lock, 
> in exactly the same way that a modern desktop OS will page out inactive 
> portions of one process to free up memory for other processes.

  It was not a question of accessing locked files. It was a question of
leaking open file handles: At some point the OS may not given any more
of them.

  Of course one thing the OS might try is to tell the GC to make a sweep
to see if that frees any file handles (does any OS actually do this?).
However, as I said, this will work only with system resources.

> And again, there are pretty trivial techniques to prevent this from 
> being a problem. At the top of your main loop, you do a quick GC to 
> scavenge anything you accidentally freed.

  This assumes that the main loop is advanced before the amount of leaked
resources grows too large. It can alleviate the problem, but it's not a
guarantee.

  (And if the main loop is executed very often, eg. thousands of times
per second, wouldn't it cause overhead to call the GC each time?)

> And of course anything that allocated stuff on the heap has this sort of 
> problem anyway, unless you wind up essentially writing your own GC anyway.

  There are alternatives to GC which call destructors immediately when
the objects go out of scope. For example, if I'm not completely mistaken,
objective C uses reference counting.

  Someone mentioned that in C# it's possible to tell for an object that
it should be destroyed immediately when it goes out of scope (but otherwise
regular GC is performed). That sounds like a good solution to me. You get
the best of both worlds.

> >   So, basically, garbage collection takes care of memory management,
> > often at the cost of reducing the possibility of the user implementing
> > automatic management of resources other than memory. These resources may
> > be system resources, or resources in the program itself. GC seems to
> > completely disregard them.

> Only naive GC.  Of course, sophisticated GC needs support throughout the 
> system. Some systems have this.

  There's no way the OS can know about the program's internal resources
even if it cooperates with the GC engine to handle system resources.

> Other systems don't have this sort of problem at all, in that files are 
> memory resources just like "in-memory" structures, so going out of scope 
> deletes the file just like you'd expect.

  Don't stick to the file handles in particular. It was just an easy to
understand example.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Looking at Java's GC and concluding that GC sucks is like looking at 
> notepad and concluding that text processors suck.

  I can't help it. I love to hate Java.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I saw a LOL line on another conversation.
>     > > Having used Ada and C++ extensively,
>     > > I'll take Ada over C++ any day.
>     > Never having used Ada at all, I'll take Ada over C++.

  Ada may be a wonderful language, but its lack of recent popularity
means that the amount of available libraries is probably quite small.
No matter how wonderful a language is, having to reinvent wheels with
it is a major letdown.

  If I had to choose a language other than C++, I'll probably choose Java
because of the amount of libraries and portability, or C# because it
sounds a bit better than Java. (Or if efficiency is not an issue, maybe
I would just go with PHP.)

> It really is amazingly well thought out as a language. Plus they've 
> added generics

  I thought templates are evil? ;)

  It still makes be laugh out loud to remember how Java advocates
fiercely attacked C++ templates. Then, some years later, they added
some crippled template mechanism to Java (which still doesn't solve
all the issues).

> I thought that was the idea behind Vista? Most of it rewritten to .NET?

  Ah, now I understand why it's so large, heavy and slow.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> The restrictions are why people call them "references" instead of 
> "pointers", just like you call them "pointers" instead of "addresses" 
> because they can only point to one type of object. I.e., you can have an 
> integer and a float at the same address, but you can't have one pointer 
> that points to either of those.

  Actually you can:

    union IntegerOrFloat
    {
        int i;
        float f;
    };

    IntegerOrFloat* ptr = whatever;

;)

> >>  The language doesn't allow class prototypes, and claims this is 
> >> a benefit because "header files aren't necessary."
> > 
> >   This sounds like a hindrance to modularity. I assume that you can't
> > have types, functions and variables which are local to a compilation unit
> > and are completely invisible to the outside?

> Sure you can. C# has the same public/private/protected/<mumble> that C++ 
> has. With the added advantage that private variables really are private.

  The point was not whether it has public and private sections, but
whether you can implement something the class uses somewhere else than
in the class declaration, completely invisible to the rest of the program.

> >   This removes clutter from the AClass definition.

> In C#, you don't have to do anything like that. You declare AClass as 
> public, AClass::Inner as private, and you're done. You don't have to 
> pick different files to put them in to enforce who gets to see them.

  That was not my point. My point was that it's nice that I can put some
implementations in a separate file, which reduces the clutter of the
class declaration.

  In some cases I have even implemented one class in two files because
the implementation was so massive (even though the public interface of
the class was rather small). This helps keeping source code files smaller
and more manageable.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Basically, there are any number of people who say "fast is better than 
> correct" because they've never built programs where incorrectness costs 
> money or lives.

  Oh, garbage collection is the Holy Grail of programming which, magically,
makes programs "correct". Yeah. ;)

> You can't accidentally declare the function taking a float in the 
> headers and an integer in the body and have mysterious type crashes at 
> runtime in spite of your static typing.

  C# doesn't check at compile time that all your types match?

-- 
                                                          - Warp

Post a reply to this message

> Darren New wrote:
> 
>> Looking at Java's GC and concluding that GC sucks is like looking at 
>> notepad and concluding that text processors suck.
> 
> OK, *surely* this ought to be quoted somewhere prominent? ;-)

Like on Alain's signature? (He has one hell of a collection of quotes 
rotating there).

Post a reply to this message

Warp escribió:
>   In some cases I have even implemented one class in two files because
> the implementation was so massive (even though the public interface of
> the class was rather small). This helps keeping source code files smaller
> and more manageable.
> 

And back when disks were small, many libraries used to have only one 
function per compilation unit. The reason is that if you use a function 
from some object file, the linker usually adds the *whole* object file.

Post a reply to this message

Warp wrote:

>   I can't help it. I love to hate Java.

Join the freakin' club!

About the only thing Java has going for it is that it's widely 
supported. (Why does that only seem to happen for half-lame languages?)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message