5 ms·
What I find sad is that Java garbage collection isn't better than manual memory management, given the vast investment in the jvm. There are plenty of ways in wh
by saosebastiao 11y ago
What I find sad is that Java garbage collection isn't better than manual memory management, given the vast investment in the jvm. There are plenty of ways in which garbage collection can be faster, but production software is still in the stone ages when compared to research from 10 years ago.
For example, any scenario where Rust doesn't even need a lifetime annotation is a scenario where a garbage collecting language compiler still could manually manage collection at almost zero cost. It could, very simply I might add, make inferences of the most efficient way to collect block scoped objects...the vast majority of which end up getting collected in the short lifetime pool. Long lifetime objects might be more efficiently reference counted, so why can't the compiler decide that singletons should be reference counted, or even statically allocated instead of pinged during every large collection? And why can't we have an actual disposable interface that actually performs a manual collection?
For a language that is as memory heavy as Java is, with as much boxing that it does, and the high performance demands of its user base, it blows my mind that their best idea for improvement in garbage collection in the last decade was to naively go after more concurrency. I realize that is what everybody thought the future was for everything, but something something Amadahl's law. There are so many better opportunities that involve allocating less, destroying without a mark stage, etc.
- pcwalton 11y agoWhat you're describing is escape analysis and the resulting SROA. These are things that the HotSpot VM does in fact do.
- saosebastiao 11y agoThat is news to me (thanks for the clarification), but unless I'm misunderstanding you, escape analysis is only for block scoped allocations. It doesn't perform any optimizations for large and/or long lived objects so they can bypass expensive large heap mark stages, and it doesn't allow for deterministic destructor interfaces. As far as I can tell, the only industrial GC language out there attempting to do this sort of thing is Swift.
- sievebrain 11y agoDeterministic destruction RAII style is handled in GCd languages with try-with-resources or using type constructs. Modern collectors like G1 don't do full mark/sweeps of the entire heap in normal operation - only in rare cases like if you request a memory profile, or if the entire process runs out of RAM and needs to do a hard stop. And reference counting isn't something you can just automatically do due to the presence of cycles. Notwithstanding these things, you may be interested in Graal, and specifically this talk on automatic region allocation: https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=12 https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3Ar... http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637907.pdf http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637...