5 ms·

Wanna know something funnier also posted in previous thread? The hello_world.v has potential memory leaks. I tried it myself and got a similar result. Somehow t

Wanna know something funnier also posted in previous thread? The hello_world.v has potential memory leaks. I tried it myself and got a similar result. Somehow the creator cannot reproduce this. ==57519== LEAK SUMMARY: ==57519== definitely lost: 0 bytes in 0 blocks ==57519== indirectly lost: 0 bytes in 0 blocks ==57519== possibly lost: 816 bytes in 3 blocks ==57519== still reachable: 0 bytes in 0 blocks ==57519== suppressed: 0 bytes in 0 blocks [1]: https://news.ycombinator.com/item?id=31931083 https://news.ycombinator.com/item?id=31931083 edit: Got something even better. $ valgrind --leak-check=yes v examples/hello_world.v ... ==58037== LEAK SUMMARY: ==58037== definitely lost: 4,463,772 bytes in 106,561 blocks ==58037== indirectly lost: 5,275,772 bytes in 84,005 blocks ==58037== possibly lost: 0 bytes in 0 blocks ==58037== still reachable: 47,149 bytes in 263 blocks ==58037== suppressed: 0 bytes in 0 blocks ...

judge2020 4y ago
Reproduces on GitHub Actions: https://github.com/judge2020/test-v/runs/7150691976?check_suite_focus=true#step:4:11 https://github.com/judge2020/test-v/runs/7150691976?check_su...
- amedvednikov 4y ago
  Like I thought, this is some minor GC overhead. Wouldn't be there with `v -gc none hello_world.v`.
amedvednikov 4y ago
You can stop spamming this nothingburger. 816 bytes is probably due to some GC overhead. It's nothing.
- forgotpwd16 4y ago
  "Probably" doesn't cut it if someone is going to user your language. Let's agree that this isn't a serious matter though. The compiler leaking is nothing as well?
  - amedvednikov 4y ago
    It's not probably anymore, you're too late. See the message below. And no, 800 bytes is not a serious matter.
    - mihaigalos 4y ago
      I do think V is amazing and has a bright future. Thank you for putting time in it. If I may, I still believe even 1 byte is a serious matter imho.
      - amedvednikov 4y ago
        I'd agree if it was happening in a loop somewhere. And a long running web service would leak memory over time. This doesn't happen, we have V web services running for months without leaks. But since there were several responses with this message, I'll make sure valgrind reports 0 :)
      - gompertz 4y ago
        Ahhh, if only Electron or Chrome shared that sentiment =)
        mihaigalos 4y ago
        Electron or Chrome are not the topic of this thread. I also don't appreciate whataboutism, sorry.
    - the_duke 4y ago
      This type of hostile response to a very valid question is why you are not changing the opinion of many users here on HN. A leak is a valid concern, because it implies problems with memory management. "We choose to not free some memory on purpose" can be a valid explanation , but needs more context. You could be more persuasive by linking to the relevant code and explaining what memory it is and why you are leaking it. Otherwise your responses just seem like deflection.
- _gabe_ 4y ago
  Why is this a nothingburger? If you're making the claim that it's safe and it actively leaks memory, how do we know it doesn't also allow buffer overruns or double frees? It would be nice if you allowed an option to compile with memory tracking so that as a user of the language you can debug this sort of stuff to make sure it's not a big deal waiting to happen.
  - amedvednikov 4y ago
    800 bytes in some GC cleanup is not "actively leaking memory". It's a nothingburger. We know it's not a big deal, we have lots of valgrind tests running on CI. And we have V web services running for months and not leaking memory.
mayama 4y ago
I checked with valgrind too and see similar memory leaks. Is v compiler written in vlang yet? I see lot of warnings and leaks for the compiler.
- amedvednikov 4y ago
  It has been written in V from the start (the first public release). V doesn't free memory when building V for performance reasons. A compiler is a perfect example of an app where freeing memory is totally fine on exit, by the OS. Fortunately V is efficient and doesn't result in gigabytes of RAM used when compiling large bases of code (V itself is about 110k loc + 100k of vlib). Once there are code bases that require gigabytes of RAM, we'll add an option to free it as it goes.

judge2020 4y ago

Reproduces on GitHub Actions: https://github.com/judge2020/test-v/runs/7150691976?check_suite_focus=true#step:4:11 https://github.com/judge2020/test-v/runs/7150691976?check_su...

amedvednikov 4y ago
Like I thought, this is some minor GC overhead. Wouldn't be there with `v -gc none hello_world.v`.

amedvednikov 4y ago

You can stop spamming this nothingburger. 816 bytes is probably due to some GC overhead. It's nothing.

forgotpwd16 4y ago
"Probably" doesn't cut it if someone is going to user your language. Let's agree that this isn't a serious matter though. The compiler leaking is nothing as well?
- amedvednikov 4y ago
  It's not probably anymore, you're too late. See the message below. And no, 800 bytes is not a serious matter.
  - mihaigalos 4y ago
    I do think V is amazing and has a bright future. Thank you for putting time in it. If I may, I still believe even 1 byte is a serious matter imho.
    - amedvednikov 4y ago
      I'd agree if it was happening in a loop somewhere. And a long running web service would leak memory over time. This doesn't happen, we have V web services running for months without leaks. But since there were several responses with this message, I'll make sure valgrind reports 0 :)
    - gompertz 4y ago
      Ahhh, if only Electron or Chrome shared that sentiment =)
      - mihaigalos 4y ago
        Electron or Chrome are not the topic of this thread. I also don't appreciate whataboutism, sorry.
  - the_duke 4y ago
    This type of hostile response to a very valid question is why you are not changing the opinion of many users here on HN. A leak is a valid concern, because it implies problems with memory management. "We choose to not free some memory on purpose" can be a valid explanation , but needs more context. You could be more persuasive by linking to the relevant code and explaining what memory it is and why you are leaking it. Otherwise your responses just seem like deflection.
_gabe_ 4y ago
Why is this a nothingburger? If you're making the claim that it's safe and it actively leaks memory, how do we know it doesn't also allow buffer overruns or double frees? It would be nice if you allowed an option to compile with memory tracking so that as a user of the language you can debug this sort of stuff to make sure it's not a big deal waiting to happen.
- amedvednikov 4y ago
  800 bytes in some GC cleanup is not "actively leaking memory". It's a nothingburger. We know it's not a big deal, we have lots of valgrind tests running on CI. And we have V web services running for months and not leaking memory.

mayama 4y ago

I checked with valgrind too and see similar memory leaks. Is v compiler written in vlang yet? I see lot of warnings and leaks for the compiler.

amedvednikov 4y ago
It has been written in V from the start (the first public release). V doesn't free memory when building V for performance reasons. A compiler is a perfect example of an app where freeing memory is totally fine on exit, by the OS. Fortunately V is efficient and doesn't result in gigabytes of RAM used when compiling large bases of code (V itself is about 110k loc + 100k of vlib). Once there are code bases that require gigabytes of RAM, we'll add an option to free it as it goes.