Committing to a limit of a single program instance per process

[dmlloyd]

After discussing with Dan and thinking about this a bit, I've become convinced that direct support for multiple instances of a given qbicc program in a single process is not something we should bother supporting. Such support has many downsides - increasing indirection to global data, for example.

I think that we should still consider it possible to allow more than one distinct qbicc program within a single process space however. For example, as a user, if I compile a qbicc program as a shared library, I would expect to be able to use that shared library from any program (including other qbicc programs) as if it were a C library. I would also expect that the run-time initialization of that program would happen when that library is loaded (see my comments on #458 about global constructors in the binary image).

Note that GNU libc has an extension in the form of a function called dlmopen which allows a shared library to be loaded into a separate, new namespace. This mechanism would provide a potential means to allow multiple instances of a qbicc program to be loaded on operating systems which use GNU libc while retaining a reasonable amount of image sharing. I don't imagine this to be a generally supported solution, but rather a possible pragmatic option in the (probably unlikely) case that some user relies on being able to do something like this.

I intend to update #457 to this effect by storing static field values in a global object or structure, but I wanted to start a discussion here so that everyone is aware, and in case anyone has a counterpoint to present.

[DanHeidinga]

This makes sense to me. When we get to supporting multiple programs in the same address space (ie: sharedlibraries), we'll have to spend some time thinking about the ABI between them. Default choice is a pure C ABI with no objects crossing the boundary, no shared view of classes, etc. Other choices, while possible, are much harder to get right and require a lot of validation that both sides have a consistent view of things (see some of the validation required for OpenJ9's AOT code as an example of the complexity)

[dmlloyd]

An interesting aspect of limiting to a single program instance is that we might well be able to define the initial program heap statically - i.e. the serialization strategy, rather than implementing a scheme such as the one described in #309, could potentially serialize to "live" data structures in the image instead. The reason is twofold: the fact that there would be no need to solve the copy-on-write problem inherent in the multi-instance approach, and the fact that, with only one heap, it resides at a "fixed" known address already so the need for run-time fixups should be minimal (even in the compressed-reference case, particularly if we can define compressed references as being an offset against the segment's base pointer).

[dgrove-oss]

If we can reliably mmap the heap image to a fixed address, then this is viable. It's how JikesRVM dealt with loading an initial heap. The objects in this heap segment are effectively uncollectible though (because they weren't allocated normally at runtime and the memory is probably not organized in the way the GC system is expecting). If the initial heap is relatively small (or mostly immortal objects), then non collectability doesn't matter.

[DanHeidinga]

This is the approach we were taking with the openj9 snapshot+restore work. As Dave says, it all depends on reliably mmaping the heap at the right address.

With ASLR disabled, we were able to do it and to re-initialize the GC to see the mmap'd section as part of the regular heap, allowing it to be collected normally. Our experiments didn't get far enough to prove it was reliable in light of ASLR