5 ms·

One flaw in this article is that it assumes "naive malloc/free use". It assumes that a program written in C and in Java (for instance) will need to perform the

by norswap 11y ago

One flaw in this article is that it assumes "naive malloc/free use". It assumes that a program written in C and in Java (for instance) will need to perform the same amount of allocations. This is far from the truth. First, C has nested structs, whereas in Java all object references are pointers. This leads to many more allocations in Java. Second, C programmers are aware of the cost of malloc, and will try to minimize its use. Reusing memory whenever possible is common, as are some simple memory management strategy (such as arena allocation: allocate big chunks of memory, do all your work therein, then free it in one go, for instance at the one of a processing step).

lmm 11y ago
> Second, C programmers are aware of the cost of malloc, and will try to minimize its use. Reusing memory whenever possible is common, as are some simple memory management strategy (such as arena allocation: allocate big chunks of memory, do all your work therein, then free it in one go, for instance at the one of a processing step). But if you're willing to put the effort in to do something like that, there's no reason you can't do the same thing in Java.
- norswap 11y ago
  Ah but you can't. The GC will still pause and trace no matter what. As far as I know, you can only control allocation at the level of "retainment": you can keep something from being GC'ed by keeping a reference to it. Potentially you can also reuse memory. So basically, object pools. This is much less efficient than arenas, where there is one malloc and one free (or one per memory page). Also reusing memory is a bit ugly: you can't specify that things are final anymore, which you can in C -- sure this is no hard guarantee (it isn't in Java either) but it's a useful indication that during the lifetime of a "logical object" (not its memory) it will not change. I've tried using object pools a couple time in Java, whenever allocations dominated the running time, it never helped any.
  - lmm 11y ago
    > Ah but you can't. The GC will still pause and trace no matter what. The tracing can happen concurrently with the appropriate config. And I wouldn't be surprised if you could disable GC, at least for all practical purposes (e.g. only GC at 100% space usage or every 10000 years, or some such). > As far as I know, you can only control allocation at the level of "retainment": you can keep something from being GC'ed by keeping a reference to it. Potentially you can also reuse memory. So basically, object pools. This is much less efficient than arenas, where there is one malloc and one free (or one per memory page). AIUI you can do that by defining objects backed by an unsafe buffer (technically a non-public API, but there's an understanding that it will be supported and the wheels are turning towards standardizing either it or something equivalent that supports the important use cases). > Also reusing memory is a bit ugly: you can't specify that things are final anymore, which you can in C -- sure this is no hard guarantee (it isn't in Java either) but it's a useful indication that during the lifetime of a "logical object" (not its memory) it will not change. I didn't think C supported final at all? I agree that it's less convenient than it might be and a lot less convenient than standard Java, but I'm not convinced it's really any worse than what you'd be doing in C.
krylon 11y ago
> C programmers are aware of the cost of malloc, and will try to minimize its use Some C programmers, maybe. I have had discussions about GC vs. manual memory management with a few C programmers that appeared to think that malloc+free is basically free, and that GC is expensive because of, you know, GC. They still tried to avoid malloc()ing memory, but that was mainly because of problems with memory leaks and related issues. (And just to be clear, it took me very, very long to figure this out myself, mostly because none of the C programs I have worked on were affected by the performance of malloc+free. I have to give the credit to a friend who works in real time systems and one day looked at me as if I was an idiot [I might be, of course!] and told me about how in real-time code you cannot call malloc and friends, and I was like "Why not?", and then he explained it to me.)

by norswap 11y ago

lmm 11y ago

> Second, C programmers are aware of the cost of malloc, and will try to minimize its use. Reusing memory whenever possible is common, as are some simple memory management strategy (such as arena allocation: allocate big chunks of memory, do all your work therein, then free it in one go, for instance at the one of a processing step). But if you're willing to put the effort in to do something like that, there's no reason you can't do the same thing in Java.

norswap 11y ago
Ah but you can't. The GC will still pause and trace no matter what. As far as I know, you can only control allocation at the level of "retainment": you can keep something from being GC'ed by keeping a reference to it. Potentially you can also reuse memory. So basically, object pools. This is much less efficient than arenas, where there is one malloc and one free (or one per memory page). Also reusing memory is a bit ugly: you can't specify that things are final anymore, which you can in C -- sure this is no hard guarantee (it isn't in Java either) but it's a useful indication that during the lifetime of a "logical object" (not its memory) it will not change. I've tried using object pools a couple time in Java, whenever allocations dominated the running time, it never helped any.
- lmm 11y ago
  > Ah but you can't. The GC will still pause and trace no matter what. The tracing can happen concurrently with the appropriate config. And I wouldn't be surprised if you could disable GC, at least for all practical purposes (e.g. only GC at 100% space usage or every 10000 years, or some such). > As far as I know, you can only control allocation at the level of "retainment": you can keep something from being GC'ed by keeping a reference to it. Potentially you can also reuse memory. So basically, object pools. This is much less efficient than arenas, where there is one malloc and one free (or one per memory page). AIUI you can do that by defining objects backed by an unsafe buffer (technically a non-public API, but there's an understanding that it will be supported and the wheels are turning towards standardizing either it or something equivalent that supports the important use cases). > Also reusing memory is a bit ugly: you can't specify that things are final anymore, which you can in C -- sure this is no hard guarantee (it isn't in Java either) but it's a useful indication that during the lifetime of a "logical object" (not its memory) it will not change. I didn't think C supported final at all? I agree that it's less convenient than it might be and a lot less convenient than standard Java, but I'm not convinced it's really any worse than what you'd be doing in C.

krylon 11y ago

> C programmers are aware of the cost of malloc, and will try to minimize its use Some C programmers, maybe. I have had discussions about GC vs. manual memory management with a few C programmers that appeared to think that malloc+free is basically free, and that GC is expensive because of, you know, GC. They still tried to avoid malloc()ing memory, but that was mainly because of problems with memory leaks and related issues. (And just to be clear, it took me very, very long to figure this out myself, mostly because none of the C programs I have worked on were affected by the performance of malloc+free. I have to give the credit to a friend who works in real time systems and one day looked at me as if I was an idiot [I might be, of course!] and told me about how in real-time code you cannot call malloc and friends, and I was like "Why not?", and then he explained it to me.)