![](/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) |
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
|
![](/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: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
|
![](/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 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
|
![](/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 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
|
![](/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:
> 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
|
![](/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) |