BillRehmOnLine.Imported @ jos.sf.net

You're insane. I __am__ home. Good night. Drive with your eyes open.

Clark, this is an interesting conversation, but I have to call it quits. It's 1:30am my time & I get up for work at 5:30am. Need my 4 hours. I'm mailing myself both of these pages. I'll try to assemble them tomorrow.

bytecodes Sorry, I don't quite get. If you mean we're moving bytes, yeah, sure. If you mean something else, I'm missing it.

Latest GrandUnifiedMemoryModel

By MultipleMemoryManagers, I was referring to your post about "what this allows" and the one with your BathRoomBreakTM

Database=no file system? Wouldn't you call RDBMS a file system? FS: FAT tables RDBMS: catalog FS: Directory RDBMS: KeyTables FS: File RDBMS: Record

I __really__ like the idea of a GrandUnifiedMemoryModel and if it's a holy grail kind of thing, we'll just have to knock it into something reasonable. But not __too__ reasonable. That would, after all, defeat the purpose.

I spent a bunch of time looking for a good DB system for our app. We're scheduled to start a rewrite soon. Currently, we rely on our customers' existing DBMS for most persistent storage. We have a db that's local to the user machine. It's using Raima's RDB, a C DLL. The neat thing about RDM is that it's a relational-network hybrid. It actually allows for pretty clean modelling of object relationships. Raima's flagship product is Velocis. It's the same sort of hybrid.

GrandUnifiedMemoryModel "Well... the Java byte codes are the model." Missed this before. The bytecodes are the model of what, exactly? Aren't they more like the contents?

Quick prototype stuff The thing is -- they're all blocks of memory. To specialize them, we make that memory the core of an object. That's what OO systems already do. What would these memory managers do different from each other?

GrandUnifiedMemoryModel I wasn't writing it off because it was an ideal. I just meant that it's going in the opposite direction from MultipleMemoryManagers. We'd abstract the concept of memory far enough that it became irrelevant.

"persistent storage is about ignoring the difference between ram and disk and leaving it up to the operating system to handle the details." So you don't use programs that have file menus? Somebody posted a link to a really good paper about that (File menus are bad) by the VisualBasic GUI guru guy.

Isn't Oracle object-relational these days? I think the PLoP1 or PLoP2 books have a very nice pattern language about building an O-R mapping. Unfortunately, it did have code listings.

Numbered list I think we had a discussion around this idea on one of the lists. Basically, to allow a memory manager to manage persistent memory, remote objects and caching, we'd need to come up with a GrandUnifiedMemoryModel that allowed us to ignore differences between RAM and disk, RAM and net, disk and net, etc.

About the bytecodes...

Field variables: Well, sort of.. Usually, pointer math is used to calculate the offset into the object/structure. This is done by the compiler (binary compiler, not javac) and the resulting memory location is pushed onto the stack. The write of the new value just uses this location directly.
Local storage: Again, this is just pointer math and pop/push.
Creating objects & arrays: good, good
Array elements. I'm not sure what "Same thing" refers to.

MemoryManager I don't think I understand this yet. The reason that memory management is set this way is because it's a very expensive proposition __not__ to do it. Tremendous overhead. I'm sorry, you must mean something else. When I think memory manager, I'm thinking of the part of the OS that's responsible for allocating RAM, tracking available RAM, and managing paging to disk.

Serializable

I sure hope you're saving this stuff because it has to be a historic moment. The trick to using Serialization this way is to redefine what is really going on in the VM, including some richer behavior for Object.
Twice in a row. I'm joking, but I swear some times that "orthogonal" might be the perfect word to describe JOS discussions. I just thought that orthogonality would fail at sufficiently large values of N.
That __does__ sound majorly ugly.
I'm not sure if you're saying that Sprite's stuff is simple or what. If you are, I'm probably not going into enough detail. I only have one of the papers with me, and it's the one that argues for FS in the kernel, not the architecture overview. I'll try to send you a better description tomorrrow.
What I meant was that I think the ease with which people understand JOS will directly correlate with how much like Java we can keep it.

Processes I'd think that what we were looking for is saving the desktop state vs. saving a process. Or is this just a semantic difference? Or is that the way to look at it: a saved process is it's state when it was persisted. (I __know__ that's the weirdest use of the verb I've ever seen.)

About persisting processes. (What a pretty pickle.) It's pretty clear to me that they __can__ be persisted, but what is a persistent process. What is "doing something" when you save it to disk?

About using Serializable

Just because Java __says__ it's all or nothing doesn't mean __our__ VM can't be smarter about streaming. It's not exactly all or nothing, either. You can ID which fields persist.
I know what orthogonal persistence is. Basically it's a fancy way of describing going meta on the live objects. Again, there is nothing that says our VM can't save objects the way they're represented in memory. For that matter, nothing that I'm aware of dictates __how__ we represent objects in memory.
We agree on most of a whole point! I'm not sure who ODI is, but I agree it sure looks like Sun is moving to VM-level persistence.
I'm not an expert. I've only made it through 2 dense papers from their site. They integrate the file system into the kernel. The cool thing is that the file system itself operates like virtual memory -- it has pages, etc.
I don't mind about changing the kernel. I just like to extend the abstractions the interface gives us, as best we can.

WikiClone stuff

I do realize this, but would it be easier to edit stuff out than edit stuff in? Maybe we could filter this by providing a few more tags? {PutThisInTheGlossary} ? What do you think. To keep from going crazy, we'd have to build the glossary by updating existing pages.

I guess I like discussing things. When the team I lead starts to reach concensus (and it happens faster the more you interact), we start making draft documents and editing them.

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