OSDev.org

AR wrote:I am not an "everything should be open source" fanatic, what I ment is that you could pre-compile for different targets and include multiple binaries for different targets.

I may not be aware how libraries function but I was under the impression that they had .text (read-only) and local instance .data/.bss (read-write) and a global data section shared between all instances. If this isn't how it's done then, again that's a flaw in the design.

And what part of the system is going to enforce the use of this mechanism...?

I imagine the Kernel would. You provide a buffer in Kernel space to the library which the library can interact with using a pipe. If that is the only way the library can share data across instances then the programmer is going to have to use it.

It is impossible for machine code to be obsolete unless you're going to invent a system where the code is interpreted by something that doesn't require hardware.

Colonel Kernel wrote: Anyway, here's more fuel for the fire (possibly the last):

Why I like VMs (managed run-time environments? I'm not sure what to call them any more) #3: Reflection

Reflection allows for some pretty neat features at very little cost to the developer. Most of them involve the ability of the system to explore the structure of your types at run-time and use this information to transform instances of those types in some way.

A typical use of reflection is serialization. Let's say you have a big tree of objects that you want written out to a file. In C++, you could do something like make each class derive from some Serializable base class and use the Visitor pattern to traverse the tree, calling serialize() on each node, passing it an ostream. That's a lot of work for the person writing all those classes.

Colonel Kernel wrote:

AR wrote:I may not be aware how libraries function but I was under the impression that they had .text (read-only) and local instance .data/.bss (read-write) and a global data section shared between all instances. If this isn't how it's done then, again that's a flaw in the design.

That is how it's done, but in addition to that the heap is typically global to the entire process, and it plus the thread stacks are all read/write. Big problems occur when this memory gets stomped on.

And what part of the system is going to enforce the use of this mechanism...?

I imagine the Kernel would. You provide a buffer in Kernel space to the library which the library can interact with using a pipe. If that is the only way the library can share data across instances then the programmer is going to have to use it.

What you're describing is more like the client/server model in a microkernel rather than shared libraries. The good thing about this model is that it's quite robust... after all, that's why processes have separate address spaces. Unfortunately, performance would suffer way too much if every library had to communicate with the others and with the app via message-passing. The right balance between the two approaches is needed, and the balance shifts depending on the requirements of the application or system as a whole.

It is impossible for machine code to be obsolete unless you're going to invent a system where the code is interpreted by something that doesn't require hardware.

I was talking about the way applications are pre-compiled to machine code, distributed as binaries targeted to the specific platform, and run in a manner that gives the language run-time environment very little (or no) supervision over their execution and access to their own memory space.

This brings me back to my original point in the original thread, you do not need a VM to supervise execution, why? One question: How does the program do anything (ie. draw, read files, get user input, etc)? Answer: OS APIs ...snip... If the security model built into the APIs is properly designed with capabilities then the same level of security can be achieved.

    Thing* thing = new Thing();
    Foo* foo = reinterpret_cast<Foo*>( thing );
    foo->letsCrashRightNow();

Something interesting I remembered, the memory protection from not directly accessing memory is in VB6 as well, you "Set C = new Class1" to instantiate it and then it is automatically destroyed when it goes out of scope, like pre-compiled garbage collection.

If your environment doesn't have reflection, nothing prevents you to add symbolic information or generate serializer/deserializer at compile time.

Am i wrong thinking that from times to times, you still have to write code for unserialization support (e.g. when you need to *reconstruct* state rather than storing it).

When you build a Swing application, register an event handler for some widget, and then let the widget go out-of-scope without un-registering the event handler, you have a memory leak in your Java VM. The event handler is still registered and hinders the widget (and the containing frame) to be GC'ed. You also no longer have a handle on your widget, so you can't un-register the event handler.

Bottom line: I agree that VM's will play an even bigger role in the future. But they aren't the cure-all, just like the internet, thin clients, and XML were just that: Good solutions for a given problem, but not the solution to solve all problems.

As with all the things that are proclaimed to be silver bullets and kill vampires (only good), they also kill people (do bad things).

Mainly, I was just tired of hearing that VMs are for the "lazy" or less capable developers. Then again, the people that say this are the same people who would probably write everything in assembler if they could.

VB6 uses COM under the hood, so those references are really pointers to reference-counted objects. Reference counting is ok, but has its problems (cycles of objects can't be freed, there is overhead whenever references are copies around, etc.). Also, do any real work in VB6 you usually end up having to write a COM object in C++ anyway, and then things get ugly (been writing COM objects in C++ for 4 years... maybe I should not put it on my resume if I don't want to do it anymore. ).

Remember, I never said GC requires a VM, just that it's one feature of these VMs that is quite compelling.