Canonical present: Lin32 API
Announcement
Collapse
No announcement yet.
Ubuntu Is Going After A New Linux Kernel API
Collapse
X
-
Originally posted by jrch2k8 View Postgarbage collector are an aberration of nature and they normally waste more memory than they save but allow all sort of lazyness in the name "easy of use". don't believe me? try to make 2 programs one in C/C++ and other in .Net/java/JS that fill lots of ram and then clean it, the result will show you why something like that is not very welcomed since the kernel is not the place to solve lazyness
Comment
-
Originally posted by mrugiero View PostI don't think it is about laziness (I mean the proposed API, GC is about being lazy, IMO), but about being able to cache and preprocess data to use later, but allow it to be freed if really needed. Mostly caching, since if it's costly to regenerate, it shouldn't be marked as revocable, and if it isn't, then there's almost no benefit on processing it ahead of its use.
so such scenario in ARM is void, you will do that in your fat X86 server otherwise will take forever, so the only logical explanation is external data like images[and i mean a lot of them] or videos or very huge datafiles/databases that again is void to do so in ARM it will take forever[you fetch partial/sliced data from a server], games could be but you need flash based very crappy engines otherwise the framebuffer is not wide enough to process that much texturization in realtime.
so in resume with proper usage of a compiled language is really really hard to fill that much memory and keep it so long enough to starve the kernel before it get sigkill'ed.
so the point would be "give me a valid scenario where this can actually happen that deserves to be done in the kernel", so if they fail to do so, kernel devs will give an appropiate "make 3rd party devs fix their crap in userspace this is not windows"
Comment
-
Originally posted by jrch2k8 View PostSNIP
Comment
-
Originally posted by Delgarde View PostWhy would you want to write it to a file, if it's just a bunch of data you're keeping in memory? It's not like you want it persisted... it's just state that you can re-create, but which is cheaper to leave in memory. And serializing a few GB of complex structures (some of which may be unpersistable) is a hell of a lot of complexity, compared to the ability to just flag that block of memory as reclaimable and being careful about how you access it.
I'm really not seeing why people seem so resistant to this proposal... it seems like a really good idea, not to mention already available in garbage-collected languages (the GC taking the role of the kernel).
And this has NOTHING to do with garbage collection. I don't think you would be happy if your garbage collector would throw away memory you are still using.
Comment
-
Originally posted by jrch2k8 View Posti don't see point of workaround this, only few cases will ever hit such a problem and the cause will probably be crappy apps, for example:
case 1: map images or other datasets bigger than the ram itself
case 2: infinite loops putting data on memory
case 3: very long sequential algorithms putting lot of data in ram
solution 1: use slices and threads don't be an lazy bum
solution 2: bug, use valgrind
solution 3: use OOP and memory smartly, clipper age ended years ago
solution to all 3: Cgroups memory restrictions per process which is already on kernel and usable from systemd[nih though so prolly won't happen]
Comment
-
Originally posted by jrch2k8 View Posti do know this, my point is you need a real great number of concurrent applications or a very bad coding to starve the memory, specially since default this days is at least 1gb, i mean my full gentoo system with kde-4.11 + akonadi+nepomuk+ zram + ramdisk for everything + firefox 10tabs+ calligra + kernel caches don't hit the 1gb barrier and we are talking about a full fledged x86 desktop system with a bazillion deps and entire set of libraries preloaded on ram.
i can understand this predicament with java/gavik or .NET garbage collectors eating ram to optimize real crappy loops but ubuntu phone will be using c++ and QML with qt5 right? which both are very ram lightweight if coded right. so base on this i can only imagine those 3 posibilities in my previous posts to actually need something like this.
Comment
-
Originally posted by Ericg View PostWell depends on what you mean by "Regular swapping techniques" For example on my SSD I have swappiness set to 1 to make sure it doesn't swap until the last possible second. Also Cyanogenmod has zRAM support available if you enable developer mode so it doesn't TOTALLY get rid of swapping, it just adjusts the usage patterns for it.
Comment
-
Originally posted by Alejandro Nova View PostCan anybody confirm this? Is it possible to do something like what the proposed kernel API wants to do with systemd + cgroups alone?
see http://0pointer.de/blog/projects/resources.html memory limit section for systemd +cgroups
Comment
-
Originally posted by jayrulez View PostJust pointing it out: QML is also a garbage collected language.
some explanation here http://qt.developpez.com/doc/5.0-sna...2-performance/
QML is for UI design[that is as far as im willing to use it] and the logic is for Qt in c++ but well at least in QML the GC is not as bad as in Java in case devs wanna take the easy route
Comment
Comment