4 ms·

I agree that this is not a memory leak. However, the semantic distinction between "this uses much more memory than expected" and "this is a memory leak" is a l

I agree that this is not a memory leak. However, the semantic distinction between "this uses much more memory than expected" and "this is a memory leak" is a little subtle, and it seems pretty rude to call it clickbait.

devmor 3y ago
I disagree that it’s a small semantic difference. I don’t think it’s clickbait though, I think the author was just misusing terminology.
- hyperpape 3y ago
  I said it was subtle, not small. I agree it's a valuable distinction.
  - mratsim 3y ago
    A memory leak means it leaks, it's not anymore under control. Here the memory is under control, it can be reclaimed by the program.
karmakaze 3y ago
Clickbait (in the context of Rust). In languages with managed memory there are no true memory leaks so such wastes are called leaks. In lower-level languages, we should stay more strict with what we call things.
- deathanatos 3y ago
  … Box::leak¹ is a function that exists. That seems like a memory leak, no? Less tongue-in-cheek, if a program allocates far more memory than expected of it, I going to colloquially called that a "memory leak". If I see a Java program whose RSS is doing nothing but "up and to the right" until the VM runs out of memory and dies a sweet sweet page thrashing death, I'm going to describe that as a "memory leak". Having someone tell me, "well, actually, it's not a leak per se it's just that the JVM's GC didn't collect all the available garbage prior to running out of memory because …" … I don't care? You're just forcing me to wordsmith the problem description —-the problem is still there. Program is still dead, and still exceeding the constraints of the environment it should have been operating in. The author had some assumptions: that Vec doesn't overalloc by more than 2x, and that collect allocates — one of those did turn out to be false, but I think if I polled Rust programmers, a fair number of them would make the wrong assumption. I would, and TIL from this article that it was wrong, and that collect can reuse the original allocation, despite it not being readily apparent how it knows how to do that with a generic Iterator. (And, the article got me to understand that part, too!) Unlike most clickbaits which lure you in only to let you down, I learned something here. Reading it was worthwhile. ¹https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m...
  - jodrellblank 3y ago
    > "If I see a Java program whose RSS is doing nothing but "up and to the right" until the VM runs out of memory and dies a sweet sweet page thrashing death, I'm going to describe that as a "memory leak"." By this definition, if a program reads in a file and you point it to a small file then the program does not have a memory leak, but if you point it to a large enough file, then the program does have a memory leak. Whether or not a program has a memory leak doesn't depend on the code of the program, but how you use it. But then on a bigger computer, the program doesn't have a memory leak anymore. That seems a less useful definition than the parent poster's / the common definition.
    - deathanatos 3y ago
      … that's really not the idea I'm trying to convey with the comment. Clearly, if you feed a program a larger file that it is going to read into memory to process, it is then expected that it will consume more resources on account of it doing more work. But that is memory being expended on visible, useful work. All of the examples in the comment are referring to memory being "allocated" (in the sense of being assigned to the program) but not fulfilling any visibly useful function insofar as the operator/programmer can see: Java's GC being unable to effectively reclaim unused memory prior to killing a machine, the OP's example of a Vec allocating without (seemingly) have a purpose (…as it is excess of what is required to allow for amortized appends).
    - Dylan16807 3y ago
      There is an implied steady state in what the program is doing. If it goes right from "loading" to "exit" then you need a more complicated analysis. When you have that steady state, that definition looking at uncontrolled growth is more useful than trying to dissect whether the memory is truly unreachable or only practically unreachable.
  - nemothekid 3y ago
    >I don't care? You're just forcing me to wordsmith the problem description Yes, because if you don't define the problem clearly, the problem won't be solved. Java being inefficient with memory use doesn't mean any memory was leaked. Memory leaks can be tricky to track down, and if I spent 6 hours looking for a memory leak only to come back and found out you meant it uses more memory than what's efficient I'd be pissed I wasted 6 hours because you wanted to save 5 minutes.
0x457 3y ago
No, memory leak is a very distinct definition: unused and stored, but inaccessible memory. Memory leak can be as small as a single word. In this case, it's just a memory. There is another term for this scenario, which I don't remember. This is a case of optimization gone wrong, but nothing is leaked, and every single byte is accounted for. The title is click bate, but article still interesting to read.

devmor 3y ago

I disagree that it’s a small semantic difference. I don’t think it’s clickbait though, I think the author was just misusing terminology.

hyperpape 3y ago
I said it was subtle, not small. I agree it's a valuable distinction.
- mratsim 3y ago
  A memory leak means it leaks, it's not anymore under control. Here the memory is under control, it can be reclaimed by the program.

karmakaze 3y ago

Clickbait (in the context of Rust). In languages with managed memory there are no true memory leaks so such wastes are called leaks. In lower-level languages, we should stay more strict with what we call things.

deathanatos 3y ago
… Box::leak¹ is a function that exists. That seems like a memory leak, no? Less tongue-in-cheek, if a program allocates far more memory than expected of it, I going to colloquially called that a "memory leak". If I see a Java program whose RSS is doing nothing but "up and to the right" until the VM runs out of memory and dies a sweet sweet page thrashing death, I'm going to describe that as a "memory leak". Having someone tell me, "well, actually, it's not a leak per se it's just that the JVM's GC didn't collect all the available garbage prior to running out of memory because …" … I don't care? You're just forcing me to wordsmith the problem description —-the problem is still there. Program is still dead, and still exceeding the constraints of the environment it should have been operating in. The author had some assumptions: that Vec doesn't overalloc by more than 2x, and that collect allocates — one of those did turn out to be false, but I think if I polled Rust programmers, a fair number of them would make the wrong assumption. I would, and TIL from this article that it was wrong, and that collect can reuse the original allocation, despite it not being readily apparent how it knows how to do that with a generic Iterator. (And, the article got me to understand that part, too!) Unlike most clickbaits which lure you in only to let you down, I learned something here. Reading it was worthwhile. ¹https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#method.leak https://doc.rust-lang.org/stable/std/boxed/struct.Box.html#m...
- jodrellblank 3y ago
  > "If I see a Java program whose RSS is doing nothing but "up and to the right" until the VM runs out of memory and dies a sweet sweet page thrashing death, I'm going to describe that as a "memory leak"." By this definition, if a program reads in a file and you point it to a small file then the program does not have a memory leak, but if you point it to a large enough file, then the program does have a memory leak. Whether or not a program has a memory leak doesn't depend on the code of the program, but how you use it. But then on a bigger computer, the program doesn't have a memory leak anymore. That seems a less useful definition than the parent poster's / the common definition.
  - deathanatos 3y ago
    … that's really not the idea I'm trying to convey with the comment. Clearly, if you feed a program a larger file that it is going to read into memory to process, it is then expected that it will consume more resources on account of it doing more work. But that is memory being expended on visible, useful work. All of the examples in the comment are referring to memory being "allocated" (in the sense of being assigned to the program) but not fulfilling any visibly useful function insofar as the operator/programmer can see: Java's GC being unable to effectively reclaim unused memory prior to killing a machine, the OP's example of a Vec allocating without (seemingly) have a purpose (…as it is excess of what is required to allow for amortized appends).
  - Dylan16807 3y ago
    There is an implied steady state in what the program is doing. If it goes right from "loading" to "exit" then you need a more complicated analysis. When you have that steady state, that definition looking at uncontrolled growth is more useful than trying to dissect whether the memory is truly unreachable or only practically unreachable.
- nemothekid 3y ago
  >I don't care? You're just forcing me to wordsmith the problem description Yes, because if you don't define the problem clearly, the problem won't be solved. Java being inefficient with memory use doesn't mean any memory was leaked. Memory leaks can be tricky to track down, and if I spent 6 hours looking for a memory leak only to come back and found out you meant it uses more memory than what's efficient I'd be pissed I wasted 6 hours because you wanted to save 5 minutes.

0x457 3y ago

No, memory leak is a very distinct definition: unused and stored, but inaccessible memory. Memory leak can be as small as a single word. In this case, it's just a memory. There is another term for this scenario, which I don't remember. This is a case of optimization gone wrong, but nothing is leaked, and every single byte is accounted for. The title is click bate, but article still interesting to read.