This is more of a theoretical question. If jvm is implemented in go which itself is a garbage collected language, then does that jvm need a separate garbage collector to be implemented for its own operation?
1
-
1it depends on how you're managing your memory pool, if you have memory which is no longer referenced and your vm is keeping it aside without being able to reuse it, yes it's a memory leak– Marco A.Commented May 6, 2014 at 7:41
Add a comment
|
2 Answers
No, it can rely on the host language's garbage collector. Of course it has to be careful not to reference memory that is logically unreachable (unreachable from the guest program and not needed for the VM). But that is not fundamentally different from avoiding "logical memory leaks" (holding onto memory you don't need any more) in any other program written in the host language.
An example is RPython. Although it is unusual in that the RPython garbage collectors are written in (a low-level, manually-memory-managing subset of) RPython, all other RPython code acts almost entirely like an ordinary garbage-collected language. A VM written in RPython represents all guest language objects (and almost all objects needed only for its internal purposes) as garbage-collected RPython objects, rather than implementing a second GC only for the guest language. For example, in PyPy there is the W_Root base class. Everything that's in any sense a Python object inherits from it, but memory management for it and its subclasses is left to the RPython-level garbage collectors.
-
1+1. Jython, JRuby, IronPython, IronRuby, MacRuby, IronScheme, Nashorn, dyn.js, IronJS, they all don't implement a garbage collector but let the host take care of it. A much more interesting question is: can a garbage collector written in a garbage collected language garbage collect itself, and the answer is: yes! Commented May 6, 2014 at 10:15
-
@JörgWMittag - I have been thinking about a garbage collector collecting itself, and am struggling to understand how that would work. Does a GC need to do anything special to be able to collect itself? Can you recommend a reference which discusses this? Thanks. Commented Jan 13, 2016 at 1:36
-
@PaulBaker: Both on the Klein VM for Self and the Maxine Research VM do that. They have to, since they are both meta-circular VMs, i.e. they run inside of themselves. The Jikes RVM uses MMTk – The Memory Management Toolkit to implement its garbage collectors. Since MMTk is written in Java, it itself needs to be garbage-collected, and since it is used to implement the GC for the VM it is running in, it needs to collect itself. Commented Jan 20, 2016 at 9:17
Yes, it does. The reason is that garbage collection can only reclaim inaccessible resources, but what is accessible depends on the level on which you view the system.
The host VM implements garbage collection to reclaim memory that the guest program used but has now released. In your case, the guest program is another VM, and its guests are application programs. When an application program uses and discards memory, it no longer has a handle to that memory, so it can never use the values stored in it again. That, however, is a condition that only the guest VM can check.
From the point of view of the host VM, all the memory that the guest VM has passed out to the application was first passed out by the host VM to the guest VM, and the guest VM still has a handle to that memory (it has to have a handle to it, otherwise it wouldn't even be possible for the guest VM to implement garbage collection). It follows that if the guest VM doesn't reclaim a block of memory, the host VM can't reclaim that memory either, resources will leak and you may eventually run out. In general, garbage collection or another form of resource reclaiming is necessary for every level of virtualization that involves a change of ownership of physical resources.
answered May 6, 2014 at 8:18
-
You say the guest VM needs to hold references to otherwise unreachable guest objects to implement GC on its own (this is correct), but that doesn't mean it has to implement its own GC in the first place: If the guest VM didn't attempt to implement GC itself, it wouldn't need those references and hence could let the host GC do its job. Note that when every guest object is a host object, guest-level references can be mapped to host-level references directly, i.e., in a manner transparent to the host GC.– user7043Commented May 6, 2014 at 8:47