ProcessQuotes.Imported @ jos.sf.net

ProcessPages

Process Stuff

We, at the JOS Project, are responsible... [A34]
Hm, after reading ur email, I got some questions. [A35]
Mostly, the JVM spec has changed... [A38]
while you can't get around using java.lang.*... [A48]
I will kindly ignore your flame. [A36]
Oh, my. I'm afraid I wasn't clear. [A40]
Oh, okay, go ahead and frame it then. [A46]
For instance any process can also be a parent process. [A45]
I imagine this getProgram method to be incredibly complex... [A47]
But wait! This reminds me of something else that's important, too. [A50]
oy, here we go... :) [A51]
ugh, that would take up more memorty then Id like to think. [A49]
High quality operating systems use "partitions". [A52]
That's the way it should be. [A53]
It should be posisble to write an O/S that will run Sun's current three platforms. [A55]
the Process would be a thread then? [A56]
your underestimating... [A57]
Sounds good. [A60]

Multi-process VM

The current plan is to continue work on decaf+JJOS as a single-process VM until it has a class library and is fully functional [A63]
Excellent plan! [A64]
Primarily because multiple native threads/processes is an enourmous project for the kernel author. [A65]

process: scheme vs. process: subscheme

The latest design for Smart API defines a process: scheme. [A418]

Process Diagrams

It is important to understand the difference between the classic design and JNI design of a virtual machine. [A419]
Well, for byte code though, since its so core to the os, and will be used and reused so much... [A420]

[multiple process] Is it that simple?

I have been working on the problem... [A424]
AFAIK, because the native code is not bound by privacy restrictions. [A425]
Will a new process get started by "forking"...? [A426]
Luckily, we're not limited to UNIX conventions. [A427]
Personally, I prefer the standard way of creating a new process in Java. [A428]
Well, Runtime.exec() does, but I do see your point. [A430]
The classloader only sees System.in/out/err once... [A431]
With a custom implementation of java.lang.Runtime and a simple shell... [A440]
I think they do something with statics, but I don't remember for sure. [A432]
Yes, Echidna creates wrapper classes for the System.in/out/err statics... [A433]
findSystemClass() isn't just called to save memory. [A434]
If they were referenced by the calling code /before/ the call to the classloader, they've already been loaded... [A435]
Well, they've already been defined. [A438]
Is this an accurate summary? [A439]
We agree so far... [A441]
Let's consider two scenarios. [A443]
We /have/ to consider all objects for illegal casts by default for this to work transparently. [A444]
No, it doesn't. [A445]
I believe so, and it matches my interpretation of the JVM spec. [A447]
I may have misunderstood. [A448]
Note: This is a very long email. * [A449]
This is exactly right. We need one primordial class loader for each process. [A452]
Yes, you are right to point out the bootstrapping problem. However, I would solve it in a different way. [A461]
OK, just to make sure I got your proposal straight: we have multiple native primordial classloaders to generate our disjoint classloaders for multiple processes. [A462]
I wasn't thinking they'd be native, but if that's easier to do... I'd actually prefer to do it Gilbert's way. [A463]
OK -- /I/ think doing it natively will be easier, if for no other reason than we'll be /sure/ that the problems with it aren't in the Java/native interface we'd be simultaneously debugging. [A464]
Fair enough. [A465]
There may be another reason, depending on how one implements security. [A466]
[A468]

[multiple process] Saving memory

I don't like this solution for two reasons. [A442]

[multiple process] Change the sequence

Every (user-space) process is started by some other process, except for init, which is started by the kernel. [A466]

[multiple process] Compiling bytecode

It is important to know your applications when building an operating system. [A454]
It's up to the shell. [A456]
There are several ways one might want invoke a program: [A459]

[multiple process] Invoke-able

In an earlier message, when I wrote "runnable", I meant "invoke-able". [A455]

[multiple process] Critical methods

Let's assume -- for the sake of discussion -- that we have a multiple primordial class loader in machine code (MPCL/M). [A458]

[multiple process] Boot classes

Classes required at boot-time are "boot classes". [A467]

Java Processes: Final Summary?

Processes can be defined as two or more threads with disjoint memory spaces, where each group of threads (ThreadGroup or not) which shares a memory space constituting a process. [A477]
As promised, here is my response to _Quinn's final summary. [A498]
Thanks for the review. [A500]
Sounds fine. [A507]
That is, it will always allow 'illegal' casts, because you can only ever be in a position to make them if the access control allows you. [A508]
Then when is an object flagged? [A509]
We are so close to the right answer. [A510]
...the efficiency benefit I was considering is actually rather small, because you could code the instanceof/checkcast stuff to call a function to compare if two classes/interfaces are the same... [A511]
I see it the other way around. [A512]
Although I would personally choose to adopt the semantics of object ownership you just described, I wouldn't rule out "changing" them. [A513]
I think flags are still useful if we use Gilbert's byte cache and apply it to user defined class loaders. [A514]
Any form of IPC can be implemented in terms of any other form of IPC. [A515]
A link in a file subsystem is a useful analogy to the object graph in a MPCL-compatible virtual machine. [A516]
Earlier, I offered an equivalent example in the Java programming language and used bytecode instead of class definition. [A517]
w.r.t. to the ownership of JavaProcess objects, it has occured to me that we could do things the UNIX way. [A518]
Well, from here in the JVM trenches, they're not, but yeah, I think I see where you were coming from. [A519]
This points out the problem with this approach. [A523]
Proxies are not required to do this (as I explained in response to Gilbert's email). [A524]
There appears to be some confusion in the understanding of Gilbert's bytecode cache. [A525]
Quite right. I don't think I was confused as to Gilbert's proposal; his phrasing, does not consider (2), which is absolutely necessary -- for the reasons I'd outlined previously. [A531]
What the pid idea does is create an implicit proxy for us, so that we can have JavaProcesses without having to develop an object-sharing infrastructure, and the same with sockets. [A532]
This message concerns Ryan's response to Gilbert's implementation of object-sharing by proxy/ownership lists. [A533]
Yes, it appears that was the case. [A534]
So, the nativ package (do we call it the decaf sub-package now?) could initially do it this way. [A539]
It so happens that ProcessClassLoader has a reference to the process that it is loading classes for. [A540]
I see why the process which originated object might want to maintain a reference to the shared object; I don't see that this reference needs to be any different than any other kind, or have tha distinction maintained by the kernel. [A541]
It's the other way around, actually. [A551]
I begin to see the light. [A552]
The key reference when talking about the GC is the reference from the shared object to its owning process (via the ProcessClassLoader). [A554]
A kernel does not care how real or virtual memory is used. [A556]
Which is maintained in the kernel. [A557]
True, and me and Ryan have been abusing terminology mercilessly throughout this discussion, and really ought to stop. :) [A558]
I'm not sure this is a good idea. [A561]
Admittedly, this is the pathological case... [A562]

[multiple process] Terminology

As we have seen, "redundent" classes are a good thing. [A481]

[multiple process] Kernel class loader

Eventually, something must be added to reduce redundent bytecode. [A480]
I think I can agree with that; I mentioned earlier that class definition and bytecode caches can co-exist. [A484]

[multiple process] Stumped, again

I have searched and searched; but, I cannot find anything that prevents us from sharing class definitions for all class loaders, both primordial and custom. [A535]
...we can no longer allow object sharing simply because the class definitions are the same (as you had thought). [A542]
My current understanding -- and Ryan's, apparently -- is that we can share bytecode as prolificly (sp?) as we like. [A544]

Content of these pages are owned and copyrighted by the poster.
Hosted by: