Re: Java or C++?

CTips wrote:
> Rob Thorpe wrote:
> > CTips wrote:
> >
>
> >>
> >>There is a disconnect between the last use and the expiry of the last
> >>reference to the object. GC can only kick in when the last reference has
> >>gone away. Manual reclaimation can occur as soon as the last use has
> >>occured.
> >>
> >>Nulling pointers (in an imperative language) is an attempt to move the
> >>last reference closer to the last use. However, as the example above
> >>illustrates, it may be impossible to accomplish this.
> >
> >
> > In the case you mention above then nulling could be used if it was a
> > problem. I.e. sticking (setq f nil) in the middle of the two calls.
> >
> > (defun do-it (f)
> > (let
> > ((x (do-something f)))
> > (setq f nil)
> > (do-something-very-expensive-not-using-f x)))
> >
>
> Won't help in this case. There is still an outstanding reference to f in
> the callers frame (i.e. in the stack-frame of the function which called
> f), which is why I set up the problem this way.

I'm not sure about that. In lisp every variable is bound to a value.
Values conceptually exist indefinitely, and are unchangable. In
reality they are garbage collected when they can no longer be
referenced.

In the example above f is passed into the function. Then a big
memory-consuming value is bound to f in "do-something" then sometime
later the f is set to nil.

This means that after f is set to nil the big value is not bound to any
variable, and may be garbage collected if the GC decides to. Generally
a lisp implementation will check if it's necessary to GC every few
allocations. So, if "do-something-very-expensive-not-using-f" does
lots of allocation then the memory will be recycled.

If f was already bound to a lot of memory when it enters do-it then
of-course that memory cannot be freed in do-it.

> > (It's worth mentioning also that an optimizing compiler may be able to
> > remove this problem. But I doubt it would.)
>
> It might have to do interprocedural dead code elimination to resolve the
> problem. I don't necessarily see that happening, particularily in LISP.

Yes. It would only be useful in few situations so I doubt anyone has
done it.

> > As I think we both agree, GC must be used intelligently in any
> > language.
> >
>
> Absolutely.
>
> GC does not change the fundamental problem for the programmer - where is
> the last use of this particular object? After we have determined that,
> in the case of manual memory management we have to explicitly deallocate
> the object, in the case of GC we have to remove all references to the
> object.
>
> If the programming is sloppy, then we end up with leaks in both cases:
> in manual management, because objects are not deallocated, in GC because
> false references are preserved.

Yup

> GC has 2 advantages for sloppy programming/programmers:
> - it avoids the dangling reference problem
> - it (arguably) uses less memory than sloppy manual deallocation
> [the reason it is arguable is that GC has a certain built-in overhead of
> extra memory usage (tags/reference-counts/generation pools) that may be
> more than the extra memory leaked because of sloppy manual deallocation].

If it has these advantages, then it has them for programmers of any
kind, sloppy or otherwise.

I generally know when memory is no longer used in my programs. That
doesn't mean that I necessarily want to have to code it into the
program. If there's a way around it then in many cases it's sensible
to use it.

It also obviates the need to write complex code to free things. Lets
say I have a program that contains a large table to which are attached
lists. The table and its contents have ceased to be used. Assuming no
GC the freeing code must free the lists in turn and their contents,
then free the table. If I the program were written using GC it would
only be necessary to kill last reference to the table.

> One position advocates for GC take is that it lets people write
> "acceptable quality" programs without thinking too hard about the memory
> allocation issue. This lets programs either be developed faster and/or
> with less skilled programmers. Of course, "acceptable quality" is a
> relative metric - what may be acceptable to you might be symptomatic of
> rank incompetence to me.

I look at it like this: I can handle memory allocation myself, and if I
pay attention it will work correctly and effectively. Or I can allow a
garbage collector to handle some (but not all) of the issues for me,
leaving me with the remainder. I would rather do things the latter
way.

.

Relevant Pages

  • [RFC] page replacement requirements
    ... Submitting too much I/O at once can kill latency and even lead to deadlocks when bounce buffers are involved. ... Must be able to deal with multiple memory zones efficiently. ... When on completion of the write to their backing-store the reference bit is still unset a callback is invoked to place them so that they are immediate candidates for reclaim again. ... For traditional page replacement algorithms this is not a big issue since we just implement per zone page replacement; ...
    (Linux-Kernel)
  • Re: 4-way Opteron vs. Xeon-IBM X3 architecture
    ... >>>The point here is that the issue concerns both speed AND capacity. ... >As to the reference, the message header points right back in this thread, ... >>>As you may suspect, I read plenty about memory systems, and I would ... >>>from the enthusiast market and assumed that it would work in the server ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Garbage Collection Issues in long-standing services
    ... I would agree that I must be holding on to some references, ... store a reference to CS so that it can use it to send data back to the client. ... > By starting another process that allocates memory, ... it does not aggressively cleanup until the amount of physical memory ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A re-announce on GCs defects
    ... It's bad for CPU/Resource intensive but memory cheap objects. ... There may be more than one strong references and you don't know when and where to call Dispose. ... Instead of calling the destructor you call Dispose if the reference counter is 0. ... Note GC in java and C# is not really an addictive as someone would argue since there is no way to do real memory management like delete obj in C++. ...
    (microsoft.public.dotnet.languages.csharp)