3 ms·

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 kee

by 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.

by norswap 11y ago

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.