3 ms·
Since the VM controls allocation of Java objects, just implement the VM to allocate the Java objects into Go's heap using Go's native allocator thereby allowing
by jsd1982 3y ago
Since the VM controls allocation of Java objects, just implement the VM to allocate the Java objects into Go's heap using Go's native allocator thereby allowing the native Go GC to clean those up when they become unreferenced.
- ninkendo 3y agoHow would one allocate Java objects using Go’s allocator, as a program written in Go? Does go provide such primitives? Naively, something like: // Called when the hosted JVM code wants to allocate func makeJVMObject() (jObj, error) { var obj = new(jObj) // on go’s heap // do stuff return obj, nil } would make sense, except how do we keep track of who’s referencing it? JVM objects have fields which tell the GC how to crawl the object tree in the mark phase (and so do Go objects), but how do we make the Go GC aware of the fields the JVM knows about? A map maybe? Hmm, I guess a map could work… the jObj struct could have a map of fields it knows about, keys being the field name and values being where they point to… Now that I think of it this probably must be how all GC’s work, they can’t rely on static information to know the fields of each type they’ve compiled, it’s gotta be something like a map somewhere. I guess I may have answered my own question here.
- paulddraper 3y agoYep :) In fact, I would go so far as to say that it's harder to implement those without Go's GC just working. https://news.ycombinator.com/edit?id=37254746 https://news.ycombinator.com/edit?id=37254746
- erik_seaberg 3y agoMost languages have “precise garbage collectors” that always know from runtime type info which bits of an object are and are not heap pointers. Sometimes you see add-on “conservative garbage collectors” that have to assume any word might be a pointer if it looks like an aligned address in an allocated page. They can’t move objects to do compaction because they’re never sure which words are not pointers. Jacobin stores an object with a slice of its field values (each boxed as “any”) and types, so Go’s precise GC would be able to trace them: https://github.com/platypusguy/jacobin/blob/main/src/object/object.go https://github.com/platypusguy/jacobin/blob/main/src/object/...