4 ms·

Fully agreed about java libraries and frameworks being more allocation-heavy than they need to be. The problem is that the libraries and frameworks are built us

Fully agreed about java libraries and frameworks being more allocation-heavy than they need to be. The problem is that the libraries and frameworks are built using the abstraction capabilities it has, and in Java, those abstraction capabilities are very allocation heavy. I'd love to see a jvm or graal implementation of ASAP memory management. The idea generally being having extremely aggressive analysis on your code, reducing heap allocations where possible, statically managing objects where they can provably infer object lifetimes, reference counting everything left over that provably can't result in cycles, and then garbage collecting everything else.

specialist 6y ago
"ASAP memory management" Do you mean this? ASAP: As Static As Possible memory management https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf
- higerordermap 6y ago
  Guess so. That paper is pretty well known.
- darksaints 6y ago
  Yes. To be clear though, the idea is already hard enough to implement, but it would be incomprehensibly hard in the JVM ecosystem. The JVM directly implements allocation decisions, but the analysis necessary for ASAP is done mostly in higher level reprensentations of code, and there is no direct API in java byte code to tell the JVM to statically allocate or reference count a specific object.
  - thu2111 6y ago
    Hardly incomprehensibly hard. It's been done already, it just never got out of the lab into the product. http://codrutstancu.com/p81-stancu.pdf http://codrutstancu.com/p81-stancu.pdf SVM has support for snapshots/isolates, where you can ~instantly instantiate a new JVM with a fresh heap. If you set your GC params such that it never really collects, you get something close to that but without the complexity.
MrBuddyCasino 6y ago
> Fully agreed about java libraries and frameworks being more allocation-heavy than they need to be. Much to the chagrin of Martin Thompson, even the standard library is affected. Avoiding allocations is something most Java programmers don't even think about, because they are not aware it might be an issue and because there is no alternative - in Go and Rust you can stack-allocate instead, in Java you can't (not really).
nicktelford 6y ago
GraalVM has Partial Escape Analysis, which improves on HotSpot's Escape Analysis by finding even more allocations that are suitable for Scalar Replacement. It's supposed to be especially well suited for highly functional code e.g. anything that makes heavy use of closures.
tom_mellior 6y ago
> reference counting everything left over that provably can't result in cycles, and then garbage collecting everything else This is interesting. I skimmed some introductory parts of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf as well as the definition of the SCAN function and searched the PDF for "reference count" to see how it does what you propose. At the moment I don't have the impression that ASAP dynamically reference counts anything. Let alone selectively reference count certain objects but use a tracing GC for others. Could you tell me where exactly to look for details? Wouldn't references from RC objects to GC objects, and vice versa, be an absolute pain to deal with?
- darksaints 6y ago
  Sorry, I seem to have partly confused this with another approach, but can't find the paper at the moment. That being said, it does read like it uses similar approaches to automated reference counting: code is inserted by the compiler to manage reference counts and eventually dispose of objects when no longer referenced. It also appears that there are approaches toward using regions and linear types where possible. I think the takeaway though is that ASAP makes as many decisions as it possibly can to statically enforce memory safety and reclamation, but building a finely grained program-specific approach toward garbage collection for anything else. Literally every distinct program would result in a distinct garbage collector tailored to that program that is inlined into the code.

specialist 6y ago

"ASAP memory management" Do you mean this? ASAP: As Static As Possible memory management https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf

higerordermap 6y ago
Guess so. That paper is pretty well known.
darksaints 6y ago
Yes. To be clear though, the idea is already hard enough to implement, but it would be incomprehensibly hard in the JVM ecosystem. The JVM directly implements allocation decisions, but the analysis necessary for ASAP is done mostly in higher level reprensentations of code, and there is no direct API in java byte code to tell the JVM to statically allocate or reference count a specific object.
- thu2111 6y ago
  Hardly incomprehensibly hard. It's been done already, it just never got out of the lab into the product. http://codrutstancu.com/p81-stancu.pdf http://codrutstancu.com/p81-stancu.pdf SVM has support for snapshots/isolates, where you can ~instantly instantiate a new JVM with a fresh heap. If you set your GC params such that it never really collects, you get something close to that but without the complexity.

MrBuddyCasino 6y ago

> Fully agreed about java libraries and frameworks being more allocation-heavy than they need to be. Much to the chagrin of Martin Thompson, even the standard library is affected. Avoiding allocations is something most Java programmers don't even think about, because they are not aware it might be an issue and because there is no alternative - in Go and Rust you can stack-allocate instead, in Java you can't (not really).

nicktelford 6y ago

GraalVM has Partial Escape Analysis, which improves on HotSpot's Escape Analysis by finding even more allocations that are suitable for Scalar Replacement. It's supposed to be especially well suited for highly functional code e.g. anything that makes heavy use of closures.

tom_mellior 6y ago

> reference counting everything left over that provably can't result in cycles, and then garbage collecting everything else This is interesting. I skimmed some introductory parts of https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf as well as the definition of the SCAN function and searched the PDF for "reference count" to see how it does what you propose. At the moment I don't have the impression that ASAP dynamically reference counts anything. Let alone selectively reference count certain objects but use a tracing GC for others. Could you tell me where exactly to look for details? Wouldn't references from RC objects to GC objects, and vice versa, be an absolute pain to deal with?

darksaints 6y ago
Sorry, I seem to have partly confused this with another approach, but can't find the paper at the moment. That being said, it does read like it uses similar approaches to automated reference counting: code is inserted by the compiler to manage reference counts and eventually dispose of objects when no longer referenced. It also appears that there are approaches toward using regions and linear types where possible. I think the takeaway though is that ASAP makes as many decisions as it possibly can to statically enforce memory safety and reclamation, but building a finely grained program-specific approach toward garbage collection for anything else. Literally every distinct program would result in a distinct garbage collector tailored to that program that is inlined into the code.