Abstractly, we need to maintain a per-thread binary state: user/system. So at any time we should know unambiguously whether the thread is in user state or system state. Note that some code (libraries, for example) may be executed in either user or system state (other code can only ever be system or only ever user). So in general it is a dynamic property, though in some cases it may be statically determinable.

If we had such a thing working (and we were not concerned about performance), then allocation could easily be made conditional on that state, so allocation would dynamically go to the appropriate heap

When thinking about this, I like to draw an analogy with system mode in an OS, as above.

A number of questions then need to be answered:

1. What is the definition of user or system mode? Without this it is hard to draw the boundaries between them Some thoughts:
a) The execution of any org.jikesrvm or org.mmtk code probably should be in system mode. One could then construct some rules which covered transitions into and out of libraries etc. Such a rule would require the creation of new packages, such as org.mmtk.helper (for example), to contain helper code which is executed by the user, in user mode, on behalf of the system (eg allocation and write barrier fast paths). That code would "trap out" to system mode on the occasions when it needed to go slow path. (See RVM-415).
b) The user heap should never contain pointers into the system heap: this is a property that any definition of the modes should presumably uphold.

2. How do we get this to work correctly? In another setting, Martin Hirzel suggested that one could write a simple function which inspected a call chain and determined whether it was currently in system or user. If one had such a function (which could be trivial if one used 1a) above), then one could call this function very regularly (every method entry?) and assert that the thread was in fact in the correct mode. Of course this would be expensive, but it could be a good way to ensure correctness.

3. How do we get this to work efficiently? Not necessarily hard, and plenty of opportunities for some fairly straightforward optimizations. However the focus should be on correctness first.

• have a call in thread to determine whether the thread is in a system or user mode
  • this could be done through setting/clearing a flag on entry/exit to a VM routine
  • this may also be done by inspection of the call stack

• have an invariant that checks that when modifying VM objects the thread is in VM mode

• have an invariant that checks VM objects are only reachable from the VM heap (and likewise for the user heap)

Any thoughts on the JTOC?

1. Maintain per-thread state (as a bit or whatever), indicating whether in user or system mode.

2. Primary prerequisite is forming a clean definition of user and system mode.

3. Given these, then ensure correctness: a) by implementing a method that dynamically determines the actual mode, and then implementing an invariant that its value matches the per-thread state, b) by implementing a write barrier which maintains the invariant that no user object points to system heap (system objects must be able to point to user heap in some particular cases, such as class objects).

4. Use 1 & 2 to selectively allocate objects into separate user and system heaps.

What is your question about the JTOC?