![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 12/10/2010 04:41 PM, Warp wrote:
> Invisible<voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 <voi### [at] dev null> wrote:
> On 12/10/2010 04:41 PM, Warp wrote:
> > Invisible<voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 14/10/2010 08:37 PM, Warp wrote:
> Invisible<voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |