Kernel 0.1, Win

[Michael David WINIKOFF]

> 
> In Message <9303210527.28963@mulga.cs.mu.OZ.AU> ,
>    Michael David WINIKOFF <winikoff@mulga.cs.mu.oz.au> wrote:
> 
> =>Kernel -- The Second Attempt 
> 
>    For the most part, I tend to agree with this view of the system.
> 
> =>[Note: We see the concept of object classes by the type of the supported meth
> ods
> =>falling out. Whether  this should be enforced by the kernel or elsewhere
> =>or not at all is open to debate]
> 
>    Types are a sticky issue. They are basically language-specific, and
> we are building a system that needs to work across languages. I don't
> think we can expect to teach the kernel about every data type that
> comes along, so I think that any type checking would have to be done
> at one or both ends of the communication rather than in the kernel.

Yes.
Do you have any suggestions on the mechanism for doing this?

> =>This does not prohibit using small objects WITHIN a single larger object it's
> =>just that these small objects can't be exported to the rest of the system.
> 
>    Unless, of course, the larger object decides to allow access via a
> method of its own.

The point is that we still have this one large object with an extra method
rather then an extra object -- for instance the "small" object doesn't have an
OID.

> 
> =>(3) Virtual Memory and Address Space
> =>	Should we have an address space that is global or local to each object.
> =>	(Note: This IS an independant issue)
> 
>    Local address spaces have the advantages of simplifying, if not
> eliminating, kernel memory allocation and reducing problems with
> growing/shrinking allocated memory regions. If we all had 48/64-bit
> virtual addresses, this would be less of an advantage, but I assume we
> want something to run on existing machines. Global address spaces have
> the advantages of facilitating code sharing and simplifying object
> addressing/communication.
> 
> =>(4) Semantics of persistance:
> =>	One way to do persistance is to simply rely on paging -- assume all
> =>	objects are in a very large memory and let paging load them in as
> =>	needed.
> =>	As Dennis has pointed out this is inefficient.
> 
>    If the objects are large and we do some intelligent things like
> prefetching, it shouldn't be too inefficient. Global vs. Local address
> space would impact this as well.
>    Of course, if you really don't want to reinvent the wheel, then we
> should have a plain, old-fashioned file system. Regardless, I don't

The point is that objects are used to implement files so a file system is not
a good term.
[Since objects would implement such thing as file indexing we don't need the 
disk front end to provide sequential byte streams -- a simple page writing
interface could be sufficient.]

> think that a persistent object system on an MMU-less system would be
> much fun to work with. I would assume that such a system would need to
> stop and checkpoint objects fairly regularly, which would be rather
> ugly from the user's point of view.

THis is all hypothetical BTW, but, I'd imagine that checkpointing objects would
be done manually.
The user would be aware that any objects not saved before a system crash would
be lost.

> 
> =>(5) Semantics of invocation
> =>	MOOSE is multitasking.
> =>	What happens in the following situation:
> =>
> =>	Object X	Object Y	Object Z
> =>	Invoke(Z,1)
> =>					Starts executing method 1
> =>			Invoke(Z,2)
> =>The three obvious possibilities are
> =>(a) Z starts another method in parallel
> =>(b) Y is blocked until Z finishes 
> =>(c) Y continues and the invocation is queued.
> 
>    I bet you knew I couldn't resist commenting on this one. :-)  As I
> have commented in the past, I prefer the semantics of (a). However, I
> understand that the system level would be better served by the
> semantics of (c). So I would suggest implementing (c) at the system
> level and building an interface to provide the semantics of (a) on top
> of (c) at the user level (i.e. a threads package.) Objects should use
> this level to formalize communication rather than the lower level
> primitives. The (a) interface may be tailored to each language, as
> necessary.

I think providing all three  at the user level is what we should do.
WHich get done at the kernel and which get done by libraries I'll leave
o experts in the area (like yourself) to decide.

>    Of course, if a language will support Futures, I would love to see
> them implemented.  For those who don't know what a Future (or Future
> Object) is, it is an object which may not have state assigned yet. The
> language can pass around references to the Future just like any other
> object, but if it tries to access its state, the process blocks until
> some concurrent entity sets the state. I'm aware of Futures from what I
> have read on a parallel language called Ellie. It may not be
> particularly relevent to MOOSE, but it is an interesting concept.
> 
>                                         Gary Duzan
>                                         Time  Lord
>                                     Third Regeneration
>                          Humble Practitioner of the Computer Arts
> 
> 
> 
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.