[Isolate-interest] any isolation API in J2SE.next will NOT be N:1 style

[Pete Soper]

Hi Sutanu,

You wrote:

> I think most in the community will be happy as long as
> "any" implementation is available in Mustang.

That's encouraging.

> Now in the "simple" implementation you mentioned, will
> there be any classloader (bootstrap,extension,system)
> sharing with the root isolate ?

This is a tricky question that's easy to misunderstand and my answer may
be easy to misunderstand. So let's expect to iterate over this a bit if
I don't get this clear enough or have missed your point.

As we probably all know by now, isolates don't share Java state, period. That 
is, each isolate's object graph and mutable statics, at a minimum, are 
absolutely unreachable by any other isolate (I mean any other isolate 
corresponding to any instance of the Isolate class. For example, given two 
isolates there could be four instances of Isolate corresponding to them: two 
in each isolate).

So I assume you're asking about metadata sharing; that is, sharing of the
immutable data and codebase state and other things like that that can loosely
be called the runtime support for Java program execution.

This is orthogonal to both the JSR-121 architecture and it's implementation, as
are general labels like "performance", "footprint", "startup", etc. 

The way I've explained this in the past is that, although these things are 
orthogonal to isolation, they tend to get discussed and, in some cases, worked 
on at the same time. 

I believe the general label "scalability" will have a correlation with 
isolation, but that will take time to become apparent and it's more about
being able to design large programs that function properly than a belief 
that there will be some reduction in the orthogonality mentioned above. I
think there's an additional way for isolation to drive scalability but 
I'll have to defer discussion of that until my thoughts are completely straight.

Some modest cross-process sharing of metadata (e.g. class info and some 
internal representations of same) is in Tiger already. It's completely
transparent and helps a lot or a little or not at all depending on what classes
your app uses and other overhead factors. And it automatically leverages as 
many JVM instances as are visible to an admin domain, so practically any
JSR-121 impl using Sun's J2SE might benefit from that without the need for 
programmers doing anything to enable the benefit (YMMV). 

There might be more of this cross-process sharing in Mustang, but believe me, 
I don't know the probability or details. 

My advice is to be patient and look for eventual access to the source code to 
know what's getting into Mustang. Communication from a Mustang technical 
spokesperson, when he/she/they are designated will be useful too. 

(I don't mean to imply Java might be going "open source", I mean there might 
be early source access schemes again, like the "CAP" program that was run for 
Tiger.)

-Pete