• (nodebb)

    TRWTF is making. The class should've been called "MemoryLeak".

    Addendum 2021-05-25 06:38: Naming*

  • (nodebb)

    There are definitely references that live much longer than needed in many (most) .NET programs (and other GC environments). However as long as it is POSSIBLE to reference the object it is NOT a memory leak... PERIOD, EOS.

    You have a list, one item has a datatable that was really only used for load, and that is part of a dataset and you are holding 10GB of objects in memory because of that unneeded reference.... NOT A MEMORY LEAK.

  • (nodebb)

    "without incrementing the reference count," -- .NET noes NOT use reference counting.... So a big fail there...

  • Hal (unregistered) in reply to TheCPUWizard

    It might be technically true that if you have a reference its not a leak but as a practical matter allocations growing without bound and no provision to defenestrate them has the same consequences for any long lived process independant of if its because its C and there is *alloc() without and accompanying free() or you have some GC'd language and you are infinitely stuffing objects into a dictionary/hash/frame/array/list of some kind.

    If you are hanging on to references of any kinda to records as opposed to just state information you fundamentally have to think about memory management if you process is either long lived or even if its a batch job but there is a possibility you could exhaust resources before you finish processing. We probably need to stop telling folks they don't need to think about memory management; because its not true, the level of abstraction might be different but the problem remains

  • Edd (unregistered)

    Memory management is closely linked with what the program does. If you setup some dumb stuff for every single class you'll have problems, memory or not.

  • Dan Bugglin (google)

    This reminded me of our own "Base" class in one of our projects.

    Really all it has is an "Id" property, and a function for getting a unique name of an object (which traverses up a parent hierarchy and concatenates all Ids together, but that code is in a Container subclass, the Base version just returns the Id.

    It also has an empty "update" function that was intended to be overridden but was never leveraged iin any generic or specific way (only one class I can think of has an update and it doesn't rely on overriding the Base one).

    There's an "equals" that just compares two objects that is designed to be overridden. Considering .NET has Ojbect.Equals I think this one is fair.

    Finally, there's this gem, which is fortunately not called anywhere in the code,:

    /**
 * Call this whenever you have no idea how to get something to work and you want it to just work.
 * @author [guy who has since left company to earn six figures somewhere else]
 */
Base.protoype.magic = function magic() {
  alert('it worked!');
}

    Side note: Those of you who are more skilled in JS may note this defines window.magic as a side effect. We did this with every function. Why? Because DreamWeaver couldn't display the names of functions in its jumplist if you didn't define them incorrectly like that! This led to all sorts of fun side effects like discovering this caused IE to create 2 copies of each function and store them in memory separately, using more RAM than was needed. Also we frequently ran into the problem of where function open() would clobber window.open and break our popups.

    Addendum 2021-05-25 10:30: Edit: "protoype" is spelled correctly in the original code.

  • Brian (unregistered) in reply to Hal
    Hal:
    ... and no provision to defenestrate them

    Yes, we definitely need some provisions to defenestrate badly-performing code (and coders).

  • GCLeak (unregistered) in reply to TheCPUWizard

    Absolutely everyone in any sizeable GC-ed language community calls it a memory leak when references are held on beyond their usefulness and/or beyond what the system/gc-mechanism can meaningfully support.

    I suggest you deal with that fact and just extend your nomenclature to encompass this meaning.

    A bit more rationale?

    1. This phenomenon does exist

    2. The phrase exists and it is quite catchy

    3. apart from vm-bugs in a gc-ed language there should be no memory leaks according to your definition

    4. yet, both the design mistakes leading to the problem and the problem itself are quite similar

  • (nodebb) in reply to Dan Bugglin

    Hmm, perhaps that was true in some older browsers, but it hasn't been the case for a long, long time: https://jsfiddle.net/L5snz8c1/

    Addendum 2021-05-25 13:46: I'm not sure about DreamWeaver, but people typically name functions so that some browsers' debuggers show the names (some deduce it automatically).

  • (nodebb) in reply to Hal

    Hal - "no provision to defenestrate them" the point is that there IS a way to do exactly that in .NET (and other GC environments).

  • (nodebb) in reply to GCLeak

    @GCLeak - "Absolutely everyone in any sizeable GC-ed language community".... Interesting, none of any of the professionals involved in the development of the .NET CLR Memory management code ever referred to it as such. [and yes, I did work with that team for many years during the development of .NET (approx) 20 years ago, and still do today].

    Now in .NET 1.0 (fixed quickly in 1.1) there was an actual bug in the GC that caused internal pointers to not update properly under certain conditions. The result was a "gap" of space between the managed heaps that could not be used at all by the CLR. This was a true memory leak and would cause programs that were 100% correct from a developers standpoint to crash after a period of time (fortunately very long, but still).

  • (nodebb) in reply to TheCPUWizard

    Hal - "no provision to defenestrate them" the point is that there IS a way to do exactly that in .NET (and other GC environments).

    Really? So the GC can come in and clean up objects even though my program still has a physically-reachable reference on them? Hal was talking about the case where the application code has references that it will no longer use, but does not clean up.

    The classic example is some sort of cache which uses today's date as part of the access key. Naturally, tomorrow, it will no longer use todays items, and equally naturally, today, it wlll not use yesterday's items, but if there isn't a clean-up routing that drops the no-longer-usable entries, the entries will stick around.

    Yes, an unbounded cache is a bug, and yes, a cache without a way to clean old entries (that won't be reused) is a bug, but remember that all memory leaks are caused by bugs. The GC cannot clean up those inaccessible entries because they are only "logically" inaccessible. They remain "physically" accessible, so the GC must not clean them.

  • Sole Purpose Of Visit (unregistered) in reply to TheCPUWizard

    I think we can all agree that it's a "resource leak," no matter what anybody calls it.

    Which I find interesting, because a traditional complaint about C and C++ is that they are prone to "memory leaks." Which isn't a very good description of what is happening. They are actually prone to "resource leaks," where the resource may or may not be memory. Network sockets or database connections spring to mind.

    In other words, to a very large extent, the same possible problems exist, mutatis mutandis, in any language you can think of, with or without GC. So, yes, I'd prefer the term "resource leak." (Even a stack overflow is basically a resource leak.)

    Of course, you have to be a major-league imbecile to implement a guaranteed resource leak such as the one in the OP.

  • Andrew Miller (google)

    "We tried letting the garbage collector do it's thing, but it threw the whole program away"

  • (nodebb) in reply to Andrew Miller

    Winning comment

  • Daniel (unregistered)

    Definition of a memory leak (according to wikipedia... Maybe not the ultimate source of definitions in this area, but IMO the definitions is a good one): In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations[1] in a way that memory which is no longer needed is not released.

    So yes: Memory that is still referenced but not longer used counts as memory leak by that definition.

  • Grunthos the Flatulent (unregistered)

    @GCLeak - I'm with TheCPUWizard - referring to it was a "Memory Leak" for something like .Net is not helpful. This just confuses the junior developers. "High Memory Usage" I find is normally caused by one of two problems. Event Handler references not being released and memory fragmentation - usually caused by developers (even at senior and above level) who do not understand the dangers of strings.

  • gnasher729 (unregistered)

    I have used JSON as a database. 200,000 records actually. However, it just sucked everything into memory where it was accessible as a dictionary, and sometimes would write everything back on a background thread. 10MB only, no problem for say an iPhone.

    But going to disk seven times for a single record? That’s just bizarre.

Leave a comment on “Making a Weak Reference”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article