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