Okay, well, I guess all I can say is that if you strive to be one of the developers who do get the chance to care about this stuff, then you should know this stuff :-).
5 karma · joined August 27, 2026
I work for the runtime team of JPG @ Oracle. We use malloc in Hotspot, quite a lot actually! Providing your JVM with a good malloc can improve the performance of the runtime, both in terms of CPU and memory, by quite a bit.
I don't think you need the details, but it's good to be aware that some mallocs are better than others, and there are multiple of them. Being aware of jemalloc is a good way of being aware of the facts I just mentioned :-).
I think that your misunderstanding comes from the fact that you base your understanding in Java semantics, but we really need to deal with the JVM's semantics. Your suggestion only makes sense when:
a) All of the typing information is preserved across a whole build b) The build is entirely static, no new classes can be loaded
Both of these are at odds with how the JVM functions. First: We lose type parameters on compilation, so we only see that Frobber extends Fun, the type parameters are lost and its usages are converted to Object.
Second: The JVM loads code by lazily loading classfiles. All classfiles are independent, and more can be added to a system.