4 ms·
I have minimal experience with compilers, but couldn't alot of these objects be dealt with using some sort of 'compile time memory management'. Essentially have
by gizmo686 12y ago
I have minimal experience with compilers, but couldn't alot of these objects be dealt with using some sort of 'compile time memory management'. Essentially have the compiler notice a point in the code after which point a given object provably has no references to it, and insert an instruction in the bytecode to immidietly dealocate that object. If the compiler can prove that an object will be dealocated this way, it can also mark it such that the GC knows to ignore it.
Is this type of system already implemented in java (or similar languages), if not, what are the drawbacks of this approach.
- wittrock 12y agoThis is called reference counting, and it's nigh-impossible to do quickly in a nondeterministic system. https://en.wikipedia.org/wiki/Reference_counting https://en.wikipedia.org/wiki/Reference_counting See this for why it's slow compared to other schemes: http://www.cecs.uci.edu/~papers/ipdps06/pdfs/1568974892-IPDPS-paper-1.pdf http://www.cecs.uci.edu/~papers/ipdps06/pdfs/1568974892-IPDP...
- adrusi 12y agoReference counting is a runtime operation, an alternative to mark-and-sweep as a GC algorithm that allows for deterministic deallocation at the cost of memory overhead. While the net time overhead will probably always be greater than mark-and-sweep's (although there are optimizations which can make them quite similar), mark-and-sweep has the disadvantage of causing infrequent, long pauses rather than a predictable uniform slowness. Reference counting is used in Python (which also has mark-and-sweep to detect reference cycles), C++ in the form of shared_ptr<T>, Rust as Rc<T>, and objective c/swift (and certianly many more). Compile time memory management refers to things like escape and ownership analysis. Escape analysis finds locals that never escape the scope they're allocated in, directly or indirectly, and allocates them on the stack rather than the heap. It's used in openJDK and probably other major JVMs, and required by the Go standard. Ownership analysis verifies that there only ever exists one live reference to an object in memory, so that a deallocation can be statically inserted whenever it leaves scope, so it doesn't become garbage. I have only seen it used in languages where there are explicit ownership annotations, such as Rust and C++. To be sure, these are not the only forms of compile time memory management, but they're probably the most versatile.
- zastrowm 12y agopersonZ mentions [1] escape analysis [2] which is kind of similar. [1] https://news.ycombinator.com/item?id=8485522 https://news.ycombinator.com/item?id=8485522 [2] http://stackoverflow.com/questions/8222561/escape-analysis-in-the-net-clr-vm http://stackoverflow.com/questions/8222561/escape-analysis-i...
- deleted 12y ago[deleted]
- DSMan195276 12y agoThere's a combo of things in Java that combine to make this hard to do unfortunately. There's no concept of reference ownership at all (Because GC makes it unnecessary). Meaning, the syntax doesn't enforce (and in some ways encourages) you to pass and store your references anywhere you want, giving them any lifetime you want. The issue with this is that if you want to insert your own deallocate call, you have to guarantee that every place the reference is passed to never attempts to store this reference. This includes already compiled code, so it already becomes basically impossible to use this optimization when you use any std library functions. When it's not compiled code, then the compiler still has to attempt to do static-analysis on the source code to attempt to figure out if it's going to store this reference somewhere or not. If the static-analysis fails to be conclusive then you have to give-up.