Darren New <dne### [at] sanrrcom> wrote:
> That was one of the premises they started with: what if nothing in the 
> OS was written in a language like C? :-)

  They will still need dynamically loadable libraries for the system to
be rational.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   It's not a question of whether it's dynamically loaded or not. It's
> a question of whether programs which are running at the same time and
> share a library use only one instance of that library, or is that library
> loaded separately for both programs.

I would think the read-only parts of the code could certainly be shared. 
There's no good reason why things like Java .class files couldn't be 
loaded into shared memory.

>   There may be speed optimization advantages when loading the library on
> a per-application basis, but at the cost of enormously increased memory
> consumption. If you have a couple of hundreds of programs using the same
> big library, if the library is loaded for every single one of them, the
> system will require huge amounts of extra RAM.

Yep. Altho I would think you would need to actually measure how much of 
the shared code is actually used and shared in modern applications.

>   Loading a dynamically loadable library does not change the program being
> executed (other than it's told where the functions it wants to call are
> located).

Um, yes, it does. Sure. There's places you can branch to after loading 
the code that you couldn't branch to before.

Or, to put it another way, say you have a C++ class, and nowhere in any 
of your code do you reference the public integer field "xyz" that's in 
that class. (Including nowhere do you invoke any methods of the class 
that reference xyz.) The compiler Singularity uses would simply not 
allocate space for that field in any of the classes. Now, if you 
dynamically loaded code and passed it an instance of that class that 
*did* reference the field, you'd be broken.

So, yes, dynamically loading code changes the executable *process*.

>   Inlining kernel code into the application makes sense only if that
> doesn't increase the memory footprint of the application considerably.

Right. You'd have to measure it. Welcome to time/space tradeoffs. ;-)

>> Check out the Singularity OS. Real live working OS, with one of the 
>> fundamental assumptions being that once you start a process, *nothing* 
>> in the executable can change. No dynamic loading, no plug-ins, etc.
> 
>   Does that mean that every application has all the system libraries
> statically linked to them, and this system library code exists in all
> of them and are loaded into memory for all of them?

Depends on what you consider to be "system library code". The system is 
broken into a large number of small processes. So there isn't really a 
whole lot of "system library code" going on there. Stuff like "open()" 
isn't in the kernel, so it's not really a library. The runtime is linked 
in staticall, yes.

Each process does have its own garbage collector, but that's good 
because each process can use a different garbage collector, depending on 
the types of garbage it collects.

I think one of the things they're looking at is indeed shared-memory 
libraries, but I don't think they've gone very far in that direction.

It did, yes, seem somewhat wasteful, and it's a research project, so 
they may not be too worried about it.  But I can't think of any 
theoretical reason why having large blocks of executable code being 
shared amongst multiple processes would be especially difficult in 
Singularity. They just haven't done it yet.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > How does that "C system below" -- which is actually machine code below -- would
> > work without hardware below, running the system?  How would java programs run
> > without the JVM?
>
>   The difference is that nobody disses the hardware (ok, they do, but in a
> different way) or the JVM, but they diss C.

They would if they were told to program in assembly or bytecode.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> That was one of the premises they started with: what if nothing in the 
>> OS was written in a language like C? :-)
> 
>   They will still need dynamically loadable libraries for the system to
> be rational.

It's possible. I suppose it also depends on (a) how much memory they 
think they'll have in machines by the time it's actually a production 
OS, and (b) what markets they're targetting.

Certainly for general desktop or server systems, you might have dozens 
of non-trivial applications running at once. In contrast, I think the 
first target environment for Singularity is something akin to TiVo, or 
Media Center, where you really don't have someone with dozens of windows 
open at once.

But sure, I can see the system evolving to put something like the 
native-code regexp library in a dedicated page of address space, loading 
it on demand, and sharing it with all the different programs that use 
that library. Or, you could just have a "regexp server" where you send 
the strings you want parsed and it returns you the results. This 
wouldn't have a whole lot more overhead than simply calling it directly, 
since you're sharing address space with the regexp server itself. It's 
not like it would have the IPC overhead it would in Windows or Linux or 
something.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:

> Oh, and btw, download that there Singularity OS. Note the almost 
> complete lack of anything remotely approaching C in the source. The use 
> of C in Singularity is approximately like the use of assembler in 
> C-based operating systems - the stuff that's impossible to do in the 
> higher-level languages, like turning interrupts into appropriate stack 
> frames and saving off registers during context switches.

Or, alternatively, House, which is a mixture of Haskell and assembly. 
(It contains 0% C.)

Of course, there's no software to run on it (unless it's written in 
Haskell - oh wait, I already said "no software", I'm repeating myself), 
and it's a highly experimental research prototype, not a production OS. 
And honestly, I doubt it'll ever be a production OS either...

Lots of very cool stuff like using the type system to ensure that 
hardware registers are accessed in the correct way, etc., but who's 
gonna use it?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Lots of very cool stuff like using the type system to ensure that 
> hardware registers are accessed in the correct way, etc., but who's 
> gonna use it?

Yeah, singularity does this with its device drivers too. Pretty cool, 
ensuring at compile time that your kernel-mode device driver doesn't 
step on anything else. :-)

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> Lots of very cool stuff like using the type system to ensure that 
>> hardware registers are accessed in the correct way, etc., but who's 
>> gonna use it?
> 
> Yeah, singularity does this with its device drivers too. Pretty cool, 
> ensuring at compile time that your kernel-mode device driver doesn't 
> step on anything else. :-)

Heh - do you remember back when a "data type" was just a thing to tell 
the compiler how many bits to allocate any whether to include the sign 
bit during comparisons? ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:

>   With all the talk about fancy new languages which are so super-efficient
> and so super-fast and so super-secure and whatever, I not seen too much
> discussion about one thing: What about dynamically loadable libraries?

GHC [currently the best Haskell compiler] used to be able to compile 
DLLs. At some point that code path bitrotted and stopped working; I'm 
not sure what the current status is.

According to the old documentation, it used to be a case of throwing a 
commond line switch, and your compiled program would call DLL versions 
of the Haskell libraries rather than being statically linked to them. 
You don't change any Haskell code, it's just a compiler switch.

Needless to say, if you have a few dozen Haskell programs, not having a 
dozen copies of the Prelude is something of a win. (!)

I'll see if I can figure out what the current status of this feature 
is... I'm curios myself.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Each process does have its own garbage collector, but that's good 
> because each process can use a different garbage collector, depending on 
> the types of garbage it collects.

  But doesn't that make each program selfish? In other words, it only takes
care of itself not running out of memory but completely disregards any other
program running in the system at the same time?

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Certainly for general desktop or server systems, you might have dozens 
> of non-trivial applications running at once. In contrast, I think the 
> first target environment for Singularity is something akin to TiVo, or 
> Media Center, where you really don't have someone with dozens of windows 
> open at once.

  In a typical modern OS there may be hundreds of processes running even
if the system has just booted up and the user has not started any program
of his own. There are all kinds of drivers, services, task managers,
window managers, firewalls... you name it. Every single one of them uses
the same system libraries (eg. typically libc plus a few others in linux).

  Just because the user has not started any program doesn't mean there
isn't a big bunch of programs running.

-- 
                                                          - Warp

Post a reply to this message