| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|
Yep. I'm in the same boat... should head home.
Basically, the memory manager would then service the request and put/get the memory from the stack. That's that.
There are a few items that need to be addressed:
Database=no file system? Well, from a users perspective, NO. They have no clue how the information is stored (unlike, say Word).
Ok. First of all, the VM reference says that object references are 32 bits. Fun. I do not think that there is a reason why we can't implement this differently as long as we meet this illusion to the corrsponding bytecodes.
For the time being, let us limit our conversation to get/set for fields of an object since this is 80% of the meat.
Lets say that our "Reference" data type is partitioned into two parts. The high word gives an address or offset in a jump table for the interface of the memory manager being used to minipulate the object. The low word is can be used by the memory manager any way we see fit.
Although this is not the best solution, it is the most obvious. This gives us 16 bits to define the memory managers (too much) and 16 bits that the memory manager can use to identify an object (too few). We could play lots of games to make this ratio a bit better, for instance we could use the first bit to denote if we are using the "normal, volitale RAM" manager. This would give us 31 bits of address space for that one manager, 15 bits for other managers, and 16 bits for the address space in that manager. Alternatively, a double dispach can be used... but these are just (important) details....
They are the interface to move information from the data store (RAM,Disk,OODBMS,RDBMS,DistributedObject,etc) to the stack.
Make sence? They are interface unified model. Processing:
Actually, most of the applcations I work with are database applications. So, yes, there is no file system. Just one big gigantic object space. And it is a shit load of code to make the illusion magical. I just keep having to reinvent this wheel again and again and again and again and frankly I'm getting sick of operating systems that don't DoTheRightThing(tm). Basically the user interface talks to the user in "their" terms. When a word processing document is finished it says "publish?" not "save?". Save is stupid. Of course it is saved.
Oracle's object-relational support is mediocre. The binding is what is really poor and needs help. Yep, actually in this years EuroPloP a rather nice 15 page paper was published on the topic. Code listings don't really help much since it lacked so much necessary detail. JavaBlend is basically the same approach.... although majorly flawed. It sits on top of JDBC. I need to spend more time to really evaluate it, but so far I am not really that impressed. I can imagine it being painfullly slow and not handling all of the distribued concerns that you need to be worried about (JDBC simply hides most of them). Anyway, a Oracle memory manager woudl talk directly to the sockets of the Oracle DBMS and leverage distribued transactions, etc the whole shebang!
In addition, different ProcessEnvironments might want to use different managers for their objects if the classes requested have not specified which one they require.
Well... the Java byte codes __are__ the model.
Sure you can say that it is an ideal, and some of the later things are a bit on the, well, shall we say, heated list? I have read Sun's papers on making distribued access the same as local acess.. they have valid points, but I think they are being overly pessimistic.
Anyway, persistent storage is about ignoring the difference between ram and disk and leaving it up to the operating system to handle the details.
It would be nice if we could make our memory management model open so that people could play around and perhaps find a practical way to do this effectively... It just might happen. (I might make access to objects in an relational Oracle database happen) Any other way to do this is just as flawed. And database programmers do not handle the errors, I say let's push it down to the memory manager level where I believe it really belongs.
About the bytecodes....
There is nothing saying that a user level memory manager might not use default kernel level memroy managers for some of the really nasty implementation stuff.
WhatThisAllows:
Hmm. Well. MemoryManger... the problem with many operating
systems is that you are forced into the memory management
policies set by the one and only memory manager. In short
I would like this monster replaceable... on a class by class
level. In this way my Order objects can be managed by
a OracleMemoryManager... etc. Bathroom break.
Well, sure desktop vs process. I need to think more on this one. However, what is a "service" in Windows? It is a program that is always running in the background - infact some services do their best to carry on as they left off.
There is another big problem with saving processes, that is transient variables.... this might make things unworkable.
But actually, saving process is only about 5% or less of what I am really after....
1. I agree here. We could use serilization to save classes. I see this as a policy of a memory manager. :) Agree here
2. Nope, nothing dictates, infact even though they say that references are 32 bits, nothing saying we can use something else as long as the VM works as expected. :) Agree here
3. ObjectStore TM They have a pre compiler that creates Load/Save methods on existing class files. Basically they modify the class files and do swizzling without help of the VM. It is a really nasty way to do it and it is not very transparent.. they use proxy objects everwhere. (The pre compiler generates a class with the identical interface that does a residency check and then delegates)
4. I am no expert here either. Just interested. I have alot of Oracle background and a math degree so it is not so rough. Simple stuff they have going.
5. Hmm. Don't get this point. Let me try to explain the Memory Manager.
Yes. Processes __can__ be persisted. This saves the users desktop right were they left off, etc. It brings up a host of problems, like locks. I guess your point is somewhat valid, what good is it. Hmm. Well it would leave the user right where they left off... plain and simple. With their "unsaved" (or I would re-name it "unpublished" ) document up in their editor...
Great! Hmm History, well Markus is the one who wrote the 1.
WikiClone and set up the mailing lists. I can get you the source if you want. Can Markus This mechinism for chatting really sucks. Goddamit! I should just write a HTTP tunneling vesion of IQC so I can get through the firewall here.
2. Hmm bit aggressive. It is not always good to put everything in the glossary.. but you recognize this. I would love a NameJustRight TM but am very afraid that it is impractical.
3. :) This is nice, sounds a bit like JavaLobby.... My vision for this is different than Java Lobby. I want people to edit other peoples stuff. This is what is different. This signing shit is for the birds. I wish for instance, that you would have edited in your comments/uncertienties and merged them with what I wrote. It ends up being much more cohesive document that way. Hmm... well I don't know.
Bill wrote: What did you think about the idea that processes don't have persistence? That's at least partially false, I guess, if we're going to put them to sleep with some sort of time slicing & paging algorithms. But maybe that works? Can we say a process has it's own ClassRepository which references the system and user repositories but contains local copies of unsafe code. This ClassRepository is part of the disk space used by the Process when it is "sleeped" by the scheduler. Sorry, can't remember the word for switched out tasks.
Well, I think that process can be persisted. If you read the grasshopper stuff they are doing it, PJama will do this in the future as well.... There is nothing saying that during the "stabiliation" process the stack is saved, etc.... We can pull really nice tricks to pull this off beacuse we are writing our own VM.
Yes it does, but it is an all or nothing kind of thing. You have to stream the object and all of its references in one big file. This does not scale to a corporate order entry system.
2. This mechanism relies on streams.
Yep. It is also slow beacuse the "saved" format is different from teh internal format. Read about Grasshopper and PJama.... they are doing what is called OthogonalPersistence
3. If we define some "default" serialization for Object in the VM or kernel that makes sense for JOS, we could persist anything we wanted to.
Yep. This is the way to go.....
4. A streaming file system can be efficient. Look up the stuff on Sprite that I added to the OS readings. It claims improved performance over Unix I/O.
Hmm. Could you educate me here?
5. I just generally like the idea that we build on Java to handle what we want, instead of hacking extra stuff in if we can help it.
I understand the concern. I want the kernel extensible. And yes, the kernel extensions will not be compatible with other VMs. My pet favorite kernel extension is persistence.
| Content of these pages are owned and copyrighted by the poster. | |
| Hosted by: |
|