Re: [Jikesrvm-researchers] Problem with LazyMmapper

[Steve B. <Ste...@an...>]

Ian,

Here's what I think the technical issues are and what their potential 
solutions are:

1. The VM runs in the same space as the application.  We know this is a 
bad thing, not just from the point of view of address space management, 
but because it confuses what should be a crisp distinction, and because 
it does not address resource management properly (see Godmar Back's PhD 
on KaffeOS for example).  I think this is the most fundamental problem.  
This won't be simple to solve.
2. Various limitations in the VM and boot loader which expect things to 
be statically nailed down.  A relocatable boot image is one part of the 
problem.  We also need infrastructure that will allow us to identify 
what is pinned down and play nicely with it.
3. Limitations in Space, both of which are relatively easy to address, 
but neither of which I've had at high enough priority to tackle: a) 
assumption of a single contiguous address range provided by the JVM 
(this is trivial, but the VM needs to provide the information to MMTk), 
and b) assumption that each space is internally contiguous (ie the 
spaces are non-interleaved).  This is also fairly simple, but I've just 
not had time to do it.

Perhaps there are more.  Of course the challenge is to identify our 
collective priorities and apply our available resources appropriately. 

Aside from this, you questioned why/whether MMTk really needed this 
level of control over the address space.  First, I want to re-iterate 
that commercial JVMs can and do play games with the address space, but 
because of issue 1. above, they can do so transparently, dynamically, 
while we must do so statically.  Second, MMTk was explicitly designed to 
promote flexibility in this area to allow exploration of GC algorithms.  
Yes, there are alternatives to the barrier Robin cited (you'll see in 
the publications list at least two papers which explore the associated 
trade-offs in depth), however, these are tradeoffs.  The classic 
object-remembering barrier which marks state in the object header is 
limited by the number of available bits in the header (perhaps just 
one).  By contrast there are very many algorithms which play more 
complex games with the address space (I'm not going to enumerate them 
here now, but a good place to start would be Darko Stefanovic's PhD thesis).

In short, there is a community of users around MMTk who depend on this 
functionality; removing that level of control is not really an option.  
Addressing Elisas' problem should be quite achievable with a combination 
of 2. & 3. above, but I think we really need to think about 1.

--Steve