http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf

Kewl. This is the sort of thing I like to hope will one day be real: 
Operating systems actually supporting something other than primitive-ass C. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 12/10/2010 04:43 AM, Darren New wrote:
> http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf

"The bookmarking collector relies on some additional
operating system support, which consists of a modest extension
to the Linux virtual memory manager (approximately six hundred
lines of code)."

I love the way that 600 LoC is considered "modest". I wonder how ****ing 
big the whole VMM is?! o_O

Still, it's an interesting paper none the less. Existing OS design seems 
to assume that you will be using manual memory management, and therefore 
you will only request as much memory as you need. That means that if you 
run out of physical memory, it must be because your application really 
does actually need that much memory.

With the rise of GC, these assumptions are no longer the case. If 
program A requests more memory, it may well be that program B could do a 
GC sweep and release a chunk of memory. But the OS doesn't even ask 
(under the outdated assumption that the answer will always be "no").

I doubt we'll be seeing sophisticated cooperation schemes any time soon, 
but I wonder how long it will be before the OS gains the ability to 
notify an application that it should release some memory is possible?

Post a reply to this message

On 12/10/2010 12:11 PM, Invisible wrote:

> I doubt we'll be seeing sophisticated cooperation schemes any time soon,
> but I wonder how long it will be before the OS gains the ability to
> notify an application that it should release some memory is possible?

Obviously I meant "if possible". *sigh*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I doubt we'll be seeing sophisticated cooperation schemes any time soon, 
> but I wonder how long it will be before the OS gains the ability to 
> notify an application that it should release some memory is possible?

  If an iPhone app is running out of memory, it will get a notification.
The app can then try to free unused data to free up memory. (This is
probably even more important now that iOS 4 supports some kind of
multitasking.)

  Of course it's not the same thing (iOS native programs are not GC'd),
but just wanted to mention it.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> I love the way that 600 LoC is considered "modest".

I imagine it's also *conceptually* modest, in that it's just the OS 
notifying the program it's *going* to swap out pages.

> I doubt we'll be seeing sophisticated cooperation schemes any time soon, 
> but I wonder how long it will be before the OS gains the ability to 
> notify an application that it should release some memory is possible?

Like AmigaOS, you mean?

I think it's more the problem that if you have large production machines 
where this would be particularly helpful, you're probably only running one 
application on them anyway. People who are worried about this sort of thing 
don't put the database server and the web server on the same machine, for 
example.

It would probably help individual desktop applications, but I suspect it's 
not going to really work its way into Linux real soon due to the general 
disdain that GC seems to have in that community.  I'd be more likely to 
expect it to show up in Windows and be plumbed into .NET first, since 
Microsoft has control over both of those. It's a shame the most popular GC 
implementations are the ones that suck so bad performance-wise.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 12/10/2010 04:41 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I doubt we'll be seeing sophisticated cooperation schemes any time soon,
>> but I wonder how long it will be before the OS gains the ability to
>> notify an application that it should release some memory is possible?
>
>    If an iPhone app is running out of memory, it will get a notification.

Mmm, that's interesting.

Then again, I presume the iPhone is fairly constrained for memory, so 
it's probably quite important to be able to do that kind of thing.

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

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> On 12/10/2010 04:41 PM, Warp wrote:
> > Invisible<voi### [at] devnull>  wrote:
> >> I doubt we'll be seeing sophisticated cooperation schemes any time soon,
> >> but I wonder how long it will be before the OS gains the ability to
> >> notify an application that it should release some memory is possible?
> >
> >    If an iPhone app is running out of memory, it will get a notification.

> Mmm, that's interesting.

> Then again, I presume the iPhone is fairly constrained for memory, so 
> it's probably quite important to be able to do that kind of thing.

  In fact, the entire Cocoa Touch library (which is the basic highest-level
GUI library you use to create iPhone apps and simple games) is designed
heavily around the concept of loading things lazily, unloading unused
things automatically (on receiving a memory warning) and reloading them
transparently when they are needed again (well, as transparently as you
can in Objective C). If an app is designed to fully utilize these Cocoa
Touch design principles, it often doesn't need to explicitly free things
because the library will do it automatically, but you can hook to the
low memory warning notification to free things you have allocated yourself.

  (Of course all this requires that you follow a more or less strict
coding practices standard, as Objective C itself offers little in the
way of automation, unlike eg. C++ or many other higher-level languages
would.)

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> On 12/10/2010 04:43 AM, Darren New wrote:
>> http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf
> 
> "The bookmarking collector relies on some additional
> operating system support, which consists of a modest extension
> to the Linux virtual memory manager (approximately six hundred
> lines of code)."
> 
> I love the way that 600 LoC is considered "modest". I wonder how ****ing
> big the whole VMM is?! o_O

Please take a guess at how many LoC the entire Linux kernel has.
Then look it up.

Post a reply to this message

>> I love the way that 600 LoC is considered "modest". I wonder how ****ing
>> big the whole VMM is?! o_O
>
> Please take a guess at how many LoC the entire Linux kernel has.
> Then look it up.

I was going to say some fairly small number. And then I remembered that 
"the Linux kernel" actually includes every Linux device driver ever 
written, for every architecture, ever. That alone means it must be 
absolutely massive. (And then there's support for every file system ever 
implemented, every network protocol ever implemented, every kind of 
block device, an entire route and firewall subsystem...)

On top of that, it has a build system the size of a small word processor 
for turning all the built-time options on and off, and you can 
reconfigure just about everything, right down to the number of bytes 
allocated to the keyboard buffer. That must involve one hell of a lot of 
CPP magic.

Add to that 60+ years of backwards compatibility code and you've got one 
very large, unmanageable codebase...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I was going to say some fairly small number. And then I remembered that 
> "the Linux kernel" actually includes every Linux device driver ever 
> written, for every architecture, ever. That alone means it must be 
> absolutely massive. (And then there's support for every file system ever 
> implemented, every network protocol ever implemented, every kind of 
> block device, an entire route and firewall subsystem...)

  Most device drivers are loaded as modules rather than being hard-coded
into the kernel.

-- 
                                                          - Warp

Post a reply to this message

On 14/10/2010 08:37 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> I was going to say some fairly small number. And then I remembered that
>> "the Linux kernel" actually includes every Linux device driver ever
>> written, for every architecture, ever. That alone means it must be
>> absolutely massive. (And then there's support for every file system ever
>> implemented, every network protocol ever implemented, every kind of
>> block device, an entire route and firewall subsystem...)
>
>    Most device drivers are loaded as modules rather than being hard-coded
> into the kernel.

Doesn't that mean they're still part of the kernel source tree though?

I do recall last time I tried recompiling the kernel, there were several 
items that you could hard-link or have as loadable modules. But either 
way, they're still part of the kernel source tree. So the kernel source 
tree would still be enormous...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Doesn't that mean they're still part of the kernel source tree though?

> I do recall last time I tried recompiling the kernel, there were several 
> items that you could hard-link or have as loadable modules. But either 
> way, they're still part of the kernel source tree. So the kernel source 
> tree would still be enormous...

  Since you can optionally include and exclude kernel modules (so that
you can eg. compile a very minimal and small kernel for a specific
device), it's debatable how much of the source code should really be
considered part of the kernel and which parts are only optional extras.

  If you only count the parts of the kernel which are necessary to compile
a binary which can be run on your computer (or on some specific device),
the source code size would be significantly smaller than if you counted
every single module ever written for it.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> Doesn't that mean they're still part of the kernel source tree though?

Not all of them. Some are, some aren't, depending on what hardware you're 
supporting.  I'm pretty sure, for example, that the device drivers for the 
custom hardware in the box I'm programming aren't what you'd call "part of 
the kernel" in any reasonable sense, since they're neither open source nor 
maintained by anyone outside the company that makes the hardware.

Stuff like USB root hub and protocol support? I'd expect that's part of the 
kernel.

So, yes, the kernel is quite big.  Much, much bigger than 600 lines. I'd be 
surprised if the virtual memory support wasn't a whole lot bigger than 600 
lines.

600 lines really isn't a whole lot of code in C. Back in college I wrote 
something like 10,000 lines for a simple library to do text-only stuff like 
input prompts, menus, help screens, report printing, etc for an insurance 
product. C is so primitive that the line count is probably at least 10x 
something equivalent in a language like Haskell.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> 600 lines really isn't a whole lot of code in C. Back in college I wrote 
> something like 10,000 lines for a simple library to do text-only stuff like 
> input prompts, menus, help screens, report printing, etc for an insurance 
> product.

  No offense, but that really doesn't say anything. I have seen people
write over 100 lines of code in C for something that could have been
written in 2 (no exaggeration).

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> 600 lines really isn't a whole lot of code in C. Back in college I wrote 
>> something like 10,000 lines for a simple library to do text-only stuff like 
>> input prompts, menus, help screens, report printing, etc for an insurance 
>> product.
> 
>   No offense, but that really doesn't say anything. 

True, but I was a pretty good programmer even back then. ;-)

The library really wasn't what I'd call "simple". It's "simple" compared to 
modern graphics stuff.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message