Another trend for the future?
Ecris le 15 mars 2005
Dans la catégorie Uncategorized |
We have sometimes the feeling that nothing really “cutting edge” has to be invented anymore for computer systems. We already have CPU power, plenty of memory and disk, 3D animation and so on. What else could impress us? What else could be useful in our day life working?
Let imagine you have some software running on your multi-threaded machine (which machine is not yet multi-threading?) and you could just stop one, two, maybe all the threads, when you want, and restart them were they was. Just freeze and restart, when you need it, maybe 3 month later. This sound a simple thing, but I never encountered an OS doing that the simple way. Just close everything and restart. We could also start another session, reach another point and compare the result from one session to another.Blaine Buxton just pointed us that system exists, and is available, on your machine, right now.
Social Bookmarking
Commentaires
6 commentaires to “Another trend for the future?”
Laisser un commentaire
Sorry Bernard, you are wrong. MS Windows allows that. Hackers masterize it : memory dumps (stack, heap, registers), stack copies, buffer overruns and you can do it with Visual C++ debugger
Troubles come with unserializable objects like db connection, XA ressource, …
What about unserializable ressources with squeak?
Of course, I am sure hackers masterize lot of things and can push Windows to its limits.
My feeling is more that Smalltalk and say, Windows, are build on totally different models, and the Smalltalk one might better fit with future hardware and needs.
In Smalltalk, the model is very simple: everything is an object, every object are instantiated in memory, and all those objects, including their inner states, can be saved on a disk as an image. A simple and elegant model invented during the sixties.
Windows come from another world where hardware and disk are very weak (remember what was the first PC, or first Apple computer?). In this world, you compile your program to allow it to run faster and you pass a lot of your code loading and saving data to disk. In today?s enterprise application we called that dbconnection, XA resource, but that?s the same idea: putting information from RAM to disk and vice/versa.
What I say, is that I don?t want anymore this ?file? menu in my office application. Given the fact my PC can run 4ghz with 2Go Ram and 500Go disk, what the hell do I need anymore to click on this ?save? icon? I want a simpler model where everything is potentially available; I start some computations, stop the PC, and restart where I was. I would like to ?save? those images for future retrieval, maybe to compare result, or for historical reasons. That?s all.
Now, I believe this model can be extended to enterprise application, where too much effort is spend today to manage this memory to disk dialogue.
OK, Bernard. I aggree your point of view about the huge amount of time spent to I/O ops.
Plz, let me do an tiny pattern analysis about the memory management in runtime system!
First, I would like to replace “Windows” by Pointer or Pseudo pointer language like C++, .NET and Java (Pointer/ref-based Language).
Pointer/ref-based Languages use a “local ID” pattern in their memory allocation processes. The new operator gets an address into the memory space (heap, stack, managed head). Address or Reference upon an address are local ID binded to the local adress space (physically, the motherboard).
When an object get a reference or a pointer from another object, you create a local tree of IDs. Then, serializing/unserializing operation is a tree re-construction process from an old tree to a new one. It’s closed to a database synchronization. Trouble comes while your object get an ID from the OS : file handle, socket handle, …
The OS process scheduler don’t care about the tree re-construction process. You cannot identify a file with his file handle beyond a OS process, beacause this is a OS-local ID.
Smalltalk uses a “global ID” pattern in his memory allocation process. Then, you don’t have to re-build (the object tree until you get an OS-local ID).
The reason why Java and .NET use the “local ID” pattern seems to be to simply the interoperability with OS routines (C/C++ in fact), but process pause/restart/clone, system virtualization (grid, …), … becomes higlhy more complicated (because the tree ID rebuild and synchro).
Regarding the trends of future, the “local ID” pattern seems to be an anti-pattern! The “global ID” pattern is ZE future oriented pattern.
The interoperability reason is false. Just look at how MS XLANG manage process state or VMware can pause/resume an entire OS.
Windows OS (next gen), CLR or JVM could integrate an global ID/local ID abstraction layer to run as Smalltalk.
What is your feeling about it?
I hope you like my post you are aggree or not, because I have a great pleasure to write it! :-)))
Julien.
Sure I enjoy you posts ! :o)) If you enjoy writing it, it?s just an enough reward for me to have opened this blog.
I think you got it with your local-id/global-id patterns. Indeed, my feeling is that JVM/CLR will converge toward a Smalltalk image management close to Smalltalk.
I expect CLR to converge first, as the applications are more obvious for desktop applications. I don?t know all the insides of Longhorn, but I hope it will not be too complex for them to forget old complex architecture reflexes and come back to something simpler.
A link to blog on a very similar topic, and same conclusion.
http://homepage.mac.com/staypufd/iblog/C158279439/E1402627400/index.html
.NET programs can and will converge!
A managed program is composed of the following parts (each part should converge! Own pace could be possible) :
- Managed Code Layer : convergence is easy (just update the CLR managed memory allocation process and introduce an object deshydratation/rehydration macanism as XLANG already does)
- .NET Framework Layer : subclass binded to OS routines should integrate a mecanism for rebuild native objects (ex dbConnection, device context handle, file handle, …) .NET framework 3, may be :-). This mecanism is Windows-version independant.
- OS Layer : Legacy is never an issue! Update it!
This is the MS strategy : .NET is end of COM, XAML provides a GUI Layer that it could compliant with the rebuild process, Longhorn uses an OS-native SQLServer engine for integrated metadata and file versionning management (this provides the file management layer (file handle shifts to unique PK) that it could compliant with the rebuild process, …
The convergence is currently in progress, My Lord!
Moreover, this is egally interesting for server components as server services, WebServices, .NET remoting components, EJB, … in an OS virtualization prespective (VMware server, grid, …) and “long running transactions” (workflow, blackboard implementation, …). FileNet P8 Process Engine and Biztalk BPM engine (XLANG) can already pause/resume process datas for months while waiting a sollicitation. Currently, it’s not perfect, of course.