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.

For example, nobody complains "UNIX signals are bad, because if you 
don't catch them, your process might have files open when it exits." No, 
the OS closes the files for you. It doesn't delete temp files, and it 
doesn't roll back half-completed transactional changes to the file 
system (e.g., it won't let you rename files such that all three change 
or none change, even if you dump core in the middle), but people don't 
seem to complain about this aspect for some reason.

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.

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.

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.

>   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.

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.

>   C# may be slightly better in this regard, though.

Syntactically, it's a bit easier, but it's essentially the same 
mechanism under the covers. It's just easier to invoke it.

>   Another problem with GC, which admittedly is often not very relevant,
> but in some cases may be, is that GC is very detrimental with regard
> to swapping.

I don't think I've demand-paged in ages. Certainly not any process I've 
let run to completion.

I've noticed that every program I use that actually uses too much data 
to conveniently fit in memory (e.g., photoshop, mysql, various other 
database-like engines) all manage their own memory-to-disk paging.

I bet you could get a speed boost by leaving out the demand-paging bits 
on modern chips and just go back to swapping and overlays in the rare 
cases where people care, and let them implement it themselves. You'd 
still probably want virtual addressing, so I don't know how much you'd 
actually save if you did this.

>   If the system was running low on memory to begin with, this can be
> quite detrimental. The system may start swapping like mad, all for
> absolutely no benefit.

I wouldn't say "no benefit". If the system is smart, it'll do a GC 
*before* it swaps out the task. That's the sort of thing I'm talking 
about: it'll save swapping time and swap space.

Erlang has a primitive called "hibernate", which does a GC on the 
process then swaps it out until it gets the next message. Normally you'd 
only do this if you expect to be idle for a while (say, the backup 
process waiting for the next scheduled backup to roll around).

>   So the question is: If you are making such an application, can you
> tell C# to *not* to use garbage collection? Is GC optional?

Not really.

-- 
   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

Warp wrote:
>   In my books Java references *are* pointers. They may have some restrictions
> compared to, for example, C pointers, but they are pointers nevertheless.

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. (And no, "void*" doesn't count void* 
points to neither, not either.)

It's really just a precision-in-terminology thing for people who make 
such distinctions in their everyday work of designing languages. :-)

>>  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.

(There's one more access class that I forget what it is, but it means 
basically visible across compilation units but not across "assemblies", 
where an "assembly" is a unit of distribution of object code, like a 
library or component. So you can have a type that's private to your 
entire graphics library, usable from everywhere inside the graphics lib 
without being visible outside it.)

>   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.

Nor, for that matter, do you need to do anything funky with private 
member variables in a class. If you don't give someone the source code, 
they don't see the private variables.

>   Usually one should completely avoid get and set methods for member
> variables. (Granted, this is not always possible, but in a well-designed
> program it can usually be mostly avoided.)

Well, in the cases where this is used, they're "properties" of the 
object. If you're setting whether the printer will print in color or 
not, you use a "property" and C# writes the setter and getter routines 
for you. It's not exposing a member variable - that's the point of 
making it a property.

-- 
   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:
> 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