Print 43 comment(s) - last by gfxBill.. on Sep 30 at 8:58 PM

Microsoft's Barrelfish operating system is an experimental OS looking to bring improved multicore performance to Microsoft's OS's  (Source: Network World)

"Barrelfish hackers and hangers-on, Zurich, August 2009 "  (Source: Microsoft/ETH Zurich)
Microsoft tests out multi-core improvements that will eventually be rolled into Windows

Microsoft has long cooked up new and experimental operating systems whose features eventually got rolled into its central Windows offerings.  Most recently it's been dabbling with Singularity, an experimental OS designed for increased reliability thanks to kernel, device drivers, and applications being written in managed SING# (an extension of C#) code.  Another test OS is Midori (not to be confused with the web browser), an OS that sandboxes applications for security and is designed for running concurrent applications, a feature geared towards cloud computing schemes.

Other recent efforts include its Windows Azure OS, a cloud computing OS currently offered for free to developers.

Now Microsoft has unveiled another new OS prototype codenamed "Barrelfish".  Barrelfish is an OS optimized to run on multi-core machines.  Namely, Barrelfish uses message passing and a database like system to pass information between cores.  Typically OS's use share memory schemes, which become very inefficient when resource demands are high.

The new OS was jointly created by ETH Zurich, a technology university, and Microsoft Research, located in Cambridge, Mass. 

Interestingly, it uses some open source BSD third-part libraries, which are "covered by various BSD-like open source licenses."  This has led to speculation that the new OS may be free and open source, not terms you typically would associate with Microsoft.

According to developers who have attended conferences on the new OS, it reportedly brings some of the Midori/Singularity sandboxing protections onboard.  Additionally, applications reportedly have an alternate route of accessing information from devices like graphics or sound cards.  A large deal of device information is reportedly stored in a central database that can be queried.

Writes developer "AudriUSA", "... instead of fully isolating program from device via driver, Barrelfish has a kind of database where lots of low level information about the hardware can be found. The kernel is single threaded and non preemptive. Scheduling is coupled with the message passing, an arrival of the message simply activates the waiting thread. It also uses a little bit of the microkernel concepts, running drivers in protected space, like L4 and in general pushing a lot into application domains."

As Intel and AMD expand their 4, 6, and 8-core lineups and approach even higher core counts, using these resources efficiently will be a crucial operating system responsibility.  It will be exciting to see what kind of improvements that Microsoft can accomplish with Barrelfish, as these improvements will surely be rolled into successors to Windows 7.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

RE: Questionable
By SublimeSimplicity on 9/29/2009 2:38:27 PM , Rating: 2
Memory isn't allocated linearly like that. A 1mb buffer is made up of 100s of blocks of memory spread out through out the physical address space on the memory chips. The MMU stitches these little blocks together so that they look linear to the CPU (and programmer). Memory fragmentation like you talk about hasn't been an issue in computers for 15+ years.

Now on a 32-bit OS fragmentation of virtual address space has started to become an issue, but 64-bit OSs allow so much virtual address space that this is no longer an issue.

RE: Questionable
By wetwareinterface on 9/29/2009 7:45:36 PM , Rating: 2
but memory buffers are lineraly allocated if at all possible. kernals don't track where the address is physically but logically they do. memory addresses in ascending order are blocked together if at all possible becuase it's easier to protect memory allocation that way. you protect your memory in a kernal space and do not allow anything else but the kernal to modify it. you watch out for rogue access of protected memory from outside the kernal and shut that down by locking memory adresses. you also have your kernal allow permission to memory for user space apps and those sit in unprotected memory. how do you do that if the memory addresses are willy nilly logically speaking?

memory fragmentation isn't the issue, the kernal having to be a massive bloated kernal just to keep track of memory is the issue. if you instead have a central storage of data of what's what and the kernal only has to track kernal memory and watch the database for rogue patterns, apps in user space can manage their own accesses leading to a smaller lighter faster kernal that can be more easily threaded.

when an app is sitting idle it is using memory all the same, when an app is sitting on a seperate core from the kernal it has to be far bigger to manage memory. unless you have a seperate means to monitor the memory usage and the kernal then only has to worry about it's own kernal space.

"I modded down, down, down, and the flames went higher." -- Sven Olsen

Most Popular ArticlesSmartphone Screen Protectors – What To Look For
September 21, 2016, 9:33 AM
UN Meeting to Tackle Antimicrobial Resistance
September 21, 2016, 9:52 AM
Walmart may get "Robot Shopping Carts?"
September 17, 2016, 6:01 AM
5 Cases for iPhone 7 and 7 iPhone Plus
September 18, 2016, 10:08 AM
Update: Problem-Free Galaxy Note7s CPSC Approved
September 22, 2016, 5:30 AM

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki