Phils Projects

For the longest time now I’ve yearned for manual memory management in Java. Being obsessive about performance has always had me pondering about the possibilities of manual memory management. Today I had a random thought on how this could be done, while still optionally having garbage collection. In this simple example, Instead of new I call alloc, which means instantiate this object away from the GC, I’ll handle it.

ArrayList strings = alloc ArrayList();
// use strings
delete strings;

I know its far more complicated than that, for example the ArrayList class has a size and elementData field, one an int primitive and the other an array of Objects. This presents a problem, how should anything that strings instantiates be handled? It seems that any primitive data types are directly allocated with the object in memory, and the array may just be a reference? I propose several workarounds for all of the problems this scenario presents:

1. Annotations

   Perhaps the compiler checks any class you try to allocate for the Managed annotation (or something of the like). This signals that this class can only be allocated, and it can only allocate as well. This option forces a separation in java between there being a garbage collected version of a data structure and a manually managed version.

2. Explicitness

   Like mentioned previously, what if new will place the object in the GC’d memory, and alloc would place the object outside of the JVM, letting it be completely handled by the OS. This would work because even though the GC can rearrange objects in memory it keeps a dictionary of the actual locations of objects in memory. All references in java really point to this dictionary to avoid losing an object reference when compaction occurs.

There’s also the problem where existing code bases may use the delete and alloc words as variables, method names, and even possibly class names. For this I suggest some intelligence in the way the compiler determines the actual meaning of the word, if it is strictly in the fashion “delete var1[, var2];” its surely not calling a method, using a delete variable, or instantiating a class (missing the period, parenthesis, or new/alloc keyword). The same could apply for alloc, if there is simply a space following it (not a period or parenthesis) it should be interpreted as manual allocation.

Pros

• Long living objects will not be inspected by the GC every time it decides to. In real-time applications (like games) this would be amazing.
• Greater control of when objects are deleted.
• The finalize method being invoked could be a guarantee.
• In environments with large amounts of memory, Java is really slow due to the massive undertaking the GC must perform, the possibe millions upon millions of objects it must analyze only to determine that they don’t need to be GC’d. With manual management these applications (which are typically this large because of the amount of data it caches) would perform theoretically many times faster

Cons

• Memory allocation by the OS is slower than the JVM. The JVM already has chunks of memory allocated to itself, meaning when you instantiate an object in Java typically you don’t need to make any calls to the OS, the JVM knows where and how to place the object.
• Inexperienced programmers may abuse the use of the alloc keyword, and not properly know how to ensure that an object is deleted. This could be avoided by the rare use of manual memory management, there are several data structures that would be greatly improved (ones that use arrays i.e. Cache), and some would greatly suffer (ones that use many references i.e. Tree). Nobody likes memory leaks, manual memory management should only be trusted to the experienced.

I can’t make any claims that this is completely possible, but with my understanding of the JVM, GC, and the research I’ve done I think this is completely plausible.

However If I’ve overlooked something, please let me know! I wouldn’t be surprised if there’s some massive problem with this that I can’t currently see.