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