Weekly Edition
Return to the Development page
| |||||||||||||
Quotes of the week
People who can't do object-oriented programming in a procedural
language perhaps don't understand object-oriented programming,
which is not about syntax, nor about enforcement, but about
deliberately choosing a narrower subset of mechanisms to produce
programs that are easier to maintain.
-- John Gilmore
It may be possible to improve the situation by adhering to the
following rules throughout your program:
-- "⚛"
on avoiding out-of-memory problems in 32-bit Go programs
Clearly Go is a superior weapon if the goal is to shoot everyone in
the foot at the same time. The GIL in python forces you to shoot
each person in the foot in sequence.
-- Kyle
Lemons(Log in to post comments)
Quotes of the week Posted Apr 13, 2012 13:47 UTC (Fri) by nix (subscriber, #2304) [Link]
<http://code.google.com/p/go/issues/detail?id=909> is impressive, in a horrible sort of way. Why on earth doesn't Go have type-accurate GC?
Quotes of the week Posted Apr 13, 2012 16:58 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
They're lazy.
Precise GCs are complex. Good precise GCs are VERY complex. You can literally count them on fingers of one or two hands.
Quotes of the week Posted Apr 13, 2012 20:21 UTC (Fri) by nix (subscriber, #2304) [Link]
Up to a point, Lord Copper.
lua-5.1.4 (precise incremental mark-and-sweep):
lua-5.2.0 (precise incremental generational):
and, as is usually true with code of that size, it takes at most an hour or two to understand it well enough to start to hack it.
(plus a couple of dozen lines elsewhere in the source tree.)
Quotes of the week Posted Apr 13, 2012 22:23 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
LUA is not really multithreaded, and that's where significant part of complexity comes from.
Right now, LUA performs GC during allocation (which is quite natural). In case of multithreading you have to stop _all_ threads at a safepoint ASAP. That's a non-trivial exercise in itself (Sun JVM uses binary patching to achieve this, MS CLR does VM tricks). Then you have to think about thread-local arenas and object migration between them, and so on.
It very quickly becomes a complicated mess.
Quotes of the week Posted Apr 16, 2012 11:05 UTC (Mon) by nix (subscriber, #2304) [Link]
Oh yes. This sort of thing is why Lua explicitly doesn't implement threads, leaving them to the hosting environment (where IMNSHO it is also often a mistake to use threads: use processes instead). Efficient multithreaded GC is a nightmare because getting the system into a consistent-enough state that any kind of GC is possible is liable to be either viciously complex or else so expensive that you might as well do a stop-the-world GC -- which is where GC's reputation for appalling performance comes from. (Lua's GC is efficient enough that I have never noticed a GC pause unless I explicitly tweaked its GC parameters to something insane -- but part of that is likely due to the whole garbage collector fitting inside the L1 instruction cache!)
Quotes of the week Posted Apr 17, 2012 0:40 UTC (Tue) by BenHutchings (subscriber, #37955) [Link]
GC forces you to trade-off time against space (memory). The more eagerly you collect, the less memory you use but the more time you take. (If you have enough memory to spare, it can end up faster than explicit memory management.)
I worked on the Windows port of Boehm's garbage collector for a while, adding support for incremental collection (which requires the ability to read and clear dirty bits in userland). As I recall, performance was reasonably good in the application I was working on. However, as the process size grew, false references seemed to become a big problem in a 32-bit address space. That's exactly the problem that the Go user is running into.
The recommendation to 'avoid struct types which contain both integer and pointer fields' indicates that their GC is distinguishing pointer-free allocations but doesn't support typed allocations (or the VM isn't providing type information). Boehm's GC does support typed allocations, but I don't know whether they're using that or something else (Google Code's code browser is pretty bad...).
Quotes of the week Posted Apr 18, 2012 18:17 UTC (Wed) by nix (subscriber, #2304) [Link]
If you use typed allocations, Boehm GC becomes partially type-accurate: it can free those allocations reliably, but still has to scan for non-type-accurate pointers.
IIRC it doesn't have a fully type-accurate mode (and given the existence of the C stack, such a mode wouldn't be much use anyhow).
Quotes of the week Posted Apr 19, 2012 15:04 UTC (Thu) by welinder (guest, #4699) [Link]
> (If you have enough memory to spare, it can end up faster than
> explicit memory management.)
Specifically for interpretations of "enough" that mean "infinite".
And even that isn't obvious. Applications -- and especially applications
Claims that overhead goes to zero when memory going to infinity have
Quotes of the week Posted Apr 20, 2012 7:22 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>Specifically for interpretations of "enough" that mean "infinite".
In practice, GC'd programs require about 2-3 more times RAM than the same manually-managed programs.
>Claims that overhead goes to zero when memory going to infinity have
For example, dynamic allocations with GC (in a multithreaded app!) can be as cheap as simply incrementing a single pointer - no atomic instructions, no locks, no nothing. That's simply not possible with manual RAM management.
These tricks generally require additional RAM to gain execution speed. I.e. the usual RAM-time trade-off.
Other techniques like escape analysis and lock elision are also somewhat hard to implement with manually-managed RAM.
Quotes of the week Posted Apr 20, 2012 8:31 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> For example, dynamic allocations with GC (in a multithreaded app!) can be as cheap as simply incrementing a single pointer - no atomic instructions, no locks, no nothing. That's simply not possible with manual RAM management.
Another example: in a generational GC, allocation of short-lived objects is near to cost-free. Objects are allocated as you describe. Then a minor GC cycle comes along, live objects get copied to a later generation and everything else just gets obliterated in one sweep without even looking at it.
Quotes of the week Posted Apr 20, 2012 11:06 UTC (Fri) by dgm (subscriber, #49227) [Link]
You can do better with explicit memory management: no need for collection cycles, no need for copying memory around. Just free all the short lived objects at once when no longer needed. Read my reply to Cyberax above.
Quotes of the week Posted Apr 20, 2012 12:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
How? With manual RAM management you can do this only if you explicitly allocate objects from a common pool.
But then you have a problem - if SOME of pool's objects need to survive longer then the WHOLE pool has to survive longer. With GC it's not a problem.
Quotes of the week Posted Apr 22, 2012 2:54 UTC (Sun) by dgm (subscriber, #49227) [Link]
Allocating long lived objects using good ol' malloc. That's how.
Quotes of the week Posted Apr 22, 2012 3:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] Yup. And what if your objects are MOSTLY short-lived, but sometimes they are not?Then you're in a world of hurt. For example, consider a generic library code:
json_value parse_value(const char *begin, const char *end)
{
json_value res;
if (value_is_int(begin, end))
res.as_int = parse_as_int(begin, end);
else if (value_is_string(begin, end))
{
//Hmm. What should I do here?
res.as_string = malloc(end-begin+1);
//strcpy, unquoting, whatever skipped
}
...
return res;
}
What allocator should I use here?Hm. That means I need to pass "allocator_ptr *" into all my functions working with dynamic RAM! And all allocations go through at least one additional level of indirection (remember, in Java ALL small-object allocations are roughly simple pointer increments). Then there's a question of API. For example, STL in C++ doesn't really support statefull allocators (speaking from experience). Plain C neatly sidesteps this problem by not having a standard library worth its name. But that's not all. Suppose that we have a network server with usual request/response cycle. It's natural to use thread-local arenas linked to the request cycle. That way you can delete everything at once at the end of the request. However, what if I want to add some asynchronousity later and offload some requests (that I know to be long running) to a separate thread? Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread or make a deep copy of arena-local objects before passing them to another thread. Both solutions are not nice. With GC I can simply pass an object reference to another thread and forget about it. No messing around with arenas, no nothing. And I get all the speed benefits of thread-local arenas with only some additional overhead. That's analogous to comparing writing code in high-level language with writing code in assembly. Yeah, it's possible to do everything high-level language can do in assembly (duh). But is it worth it?
Quotes of the week Posted Apr 22, 2012 11:12 UTC (Sun) by khim (subscriber, #9252) [Link] Suppose that we have a network server with usual request/response cycle. It's natural to use thread-local arenas linked to the request cycle. No. It's natural to use request-local arenas. You can handle request in more then one thread, but more importantly, you may want to handle more then one request in one thread! Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread or make a deep copy of arena-local objects before passing them to another thread. Both solutions are not nice. If “both solutions are not nice” then you've designed a monster. In my experince the next logical step is to send task too different process and, sometimes, to different system. At this point you need to think about these things anyway. And this happens much faster then you think: that's why Java-based creations often require monster machines to run. They don't scale - and GC is primary culprit. And I get all the speed benefits of thread-local arenas with only some additional overhead. No, you don't. When you've added GC to your system you've added such a huge latency overhead to it that everything else does not matter. Not because GC itself adds latency, but because programmers consider it as an indulgence and stop caring about memory allocation at all. It's possible to create fast and responsive GC-based system, but usually it's just as hard as to create fast and responsive system without GC. The only sane justification for GC was safety - and it failed there, too. If you consider things like It's probably possible to create massively-parallel system with millions of tiny CPUs (which will be 100 times as power-efficient as few powerful CPUs) and in this environment GC (coupled with functional programming) will be good idea, but contemporary systems are not built like that.
Quotes of the week Posted Apr 22, 2012 18:34 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>No. It's natural to use request-local arenas. You can handle request in more then one thread, but more importantly, you may want to handle more then one request in one thread!
Yes, that's what I meant. Request-scoped thread-local arenas.
>If “both solutions are not nice” then you've designed a monster. In my experince the next logical step is to send task too different process and, sometimes, to different system.
>At this point you need to think about these things anyway. And this happens much faster then you think: that's why Java-based creations often require monster machines to run. They don't scale - and GC is primary culprit.
I'm working in the area of molecular biology right now, and Java is used in apps that scale from Macbook Air up to monster clusters of machines with 64Gb of RAM.
>No, you don't. When you've added GC to your system you've added such a huge latency overhead to it that everything else does not matter. Not because GC itself adds latency, but because programmers consider it as an indulgence and stop caring about memory allocation at all.
And it usually is OK. Modern GCs have quite good throughput, so they can tolerate most of abuses just fine.
Direct comparison: modern compilers doesn't care that you write "a=b*2" instead of "a=b<<1".
>It's possible to create fast and responsive GC-based system, but usually it's just as hard as to create fast and responsive system without GC. The only sane justification for GC was safety - and it failed there, too.
Uhm. Considering that Android quite successfully uses GC for explicitly interactive tasks - I don't think GCs have failed.
Quotes of the week Posted Apr 22, 2012 20:19 UTC (Sun) by khim (subscriber, #9252) [Link] Uhm. Considering that Android quite successfully uses GC for explicitly interactive tasks - I don't think GCs have failed. Android is good example of with sufficient thrust, pigs fly just fine principle (RFC 1925. Sure, if you'll use dual-core 1.2GHz CPU and 1GHz of RAM (something like Galaxy Nexus) then you can almost reach the fluidity of iPhone 4 with it's single-core 800MHz CPU and 512MB of RAM (and if you'll use quad-code 1.4GHz one like in Samsung Galaxy S III then you can come closer still). But if you'll try cheap Android with 256MHz RAM and 600MHz CPU (basically what iPhone 3GS had) then you'll see that GC indeed comes with huge price attached. Granted, not all Android woes are GC-related, but nonetheless: the fact that Apple added ARC to iOS 5 and then dropped full-blown GC in MacOS 10.8 says volumes. You can say whatever you want about Apple, but these people know how to create fluid UI. “Full GC” was tried and apparently have been found wanting. And if anyone can afford buying good GC then it'll be the most valuable company in the world.
Quotes of the week Posted Apr 22, 2012 20:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>Android is good example of with sufficient thrust, pigs fly just fine principle
And we have that thrust. So why not use it?
I don't see anyone advocating rewriting of everything in assembly, for example.
>Granted, not all Android woes are GC-related
>The fact that Apple added ARC to iOS 5 and then dropped full-blown GC in MacOS 10.8 says volumes
Yup. You can't make a precise GC for C/Objective C. And conservative GCs suck like a hole in a spacecraft
Quotes of the week Posted Apr 22, 2012 22:58 UTC (Sun) by renox (subscriber, #23785) [Link]
>>Android is good example of with sufficient thrust, pigs fly just fine principle
>And we have that thrust. So why not use it? Because it reduces autonomy? Isn't good enough to get low latency?
>I don't see anyone advocating rewriting of everything in assembly, for example.
Quotes of the week Posted Apr 22, 2012 23:10 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>Because it reduces autonomy?
Autonomy from what?
>Isn't good enough to get low latency?
>but Android's poor audio latency tend to answer no..
Quotes of the week Posted Apr 23, 2012 6:36 UTC (Mon) by khim (subscriber, #9252) [Link] >but Android's poor audio latency tend to answer no.. Java is also used in all the manipulations of audio. All the audio-related tasks where Java is not involved (i.e.: simple playback or recordng) work fine on Android. No dropouts or anything. It's only when you need to show UI and react to it (music synthesis, etc) is where Android sucks (when compared to iOS) - i.e. precisely where Java with it's GC is involved. >Isn't good enough to get low latency? There are so much hype around Erlang, but I'm yet to see anything complex in it. Tiny bit-shufflers can be written in any language with or without GC (in fact if you'll read about Erlang's history you'll see that it was open-sourced when Ericsson decided to ban it from all new projects. It does not look like these projects become worse for the lack of Erlang and it's GC (Elang later returned but this is probably because they wanted to reuse existing Erlang investments rather then some intrinsic Erlang's advantages).
Quotes of the week Posted Apr 23, 2012 7:56 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Java is also used in all the manipulations of audio. All the audio-related tasks where Java is not involved (i.e.: simple playback or recordng) work fine on Android.
No it isn't. In fact, during the voice call audio path is quite often established _completely_ in hardware. On my fairly old Samsung Galaxy S phone I have heard only the usual 'stuttering' caused by buffer underflow when music is playing and some other process hogs the CPU/flash (often during heavy writeback activity).
>It's only when you need to show UI and react to it (music synthesis, etc) is where Android sucks (when compared to iOS) - i.e. precisely where Java with it's GC is involved.
I've tried http://causticapp.blogspot.com/ on my old tablet. Works fine.
>There are so much hype around Erlang, but I'm yet to see anything complex in it.
ejabberd? RabbitMQ? Online game engines ( http://www.vendetta-online.com/h/news.html )? Phone switches? Parts of Wall-Street trading engines?
It's quite common in some industries.
Quotes of the week Posted Apr 23, 2012 6:52 UTC (Mon) by khim (subscriber, #9252) [Link] >Android is good example of with sufficient thrust, pigs fly just fine principle I don't see anyone advocating rewriting of everything in assembly, for example. Assembly? Well… in rare cases yes, but usually no. Intrinsics work just fine and can be combined nicely with the other parts of the program written in high-level language. GC can not be easily combined with non-GC pieces, it's all or nothing proposition. Big difference.
Quotes of the week Posted Apr 23, 2012 8:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Because It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
Yet I'd prefer to be sitting under a flying pig even if it might occasionally be a bit dirty to being crushed by a falling airplane (most likely crashed by a pilot error).
>Assembly? Well… in rare cases yes, but usually no. Intrinsics work just fine and can be combined nicely with the other parts of the program written in high-level language. GC can not be easily combined with non-GC pieces, it's all or nothing proposition. Big difference.
The aforementioned MSVS is written in a mix of native code and managed code. Works just fine.
Quotes of the week Posted Apr 22, 2012 22:45 UTC (Sun) by dgm (subscriber, #49227) [Link]
> What allocator should I use here?
malloc(), obviously. Only if you find that this is slowing you down you try another approach. And there are a few:
> Whoops. Arenas stop to be a good idea because either you have to pass the whole arena to another thread
What's wrong with that? It's a perfectly nice solution: a per-request arena goes along with the request, and will be freed at the end. Passing the arena is mere pointer transfer. Clean and efficient.
> With GC I can simply pass an object reference to another thread and forget about it.
Well, we are getting to the root of the question.
YES, using a GC makes coding easier. Explicit memory management is not easy, but that's all. There's nothing that a GC can do that cannot be done with explicit allocation, but more efficient. When you control your memory usage you can exploit all the knowledge about the problem and the code that solves it, something no garbage collector could possibly ever do.
> That's analogous to comparing writing code in high-level language with writing code in assembly. Yeah, it's possible to do everything high-level language can do in assembly (duh). But is it worth it?
Sometimes. Nobody in his right mind would rewrite LibreOffice in assembly, not because it's impossible, but because the required effort. But, would you write the kernel of an embedded OS for a microcontroller in Java? Me neither, no matter how great the jitter or the garbage collector.
Quotes of the week Posted Apr 22, 2012 23:04 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>malloc(), obviously. Only if you find that this is slowing you down you try another approach.
So I'll have to rewrite quite a bit of code to track the current arena's allocator and/or resort to hacks like storing arena in a thread-local variable.
>All make sense, depending on constraints. The first one is my personal favorite as the caller controls the memory passed in anyway, so why make copies when you can return a pointer?
That's a very simple example, but things like this happen all the time in complex _desktop_ applications where speed is most important.
>What's wrong with that? It's a perfectly nice solution: a per-request arena goes along with the request, and will be freed at the end. Passing the arena is mere pointer transfer. Clean and efficient.
Even if your arena has tons of baggage from request parsing and another thread needs only few small objects?
>There's nothing that a GC can do that cannot be done with explicit allocation, but more efficient.
Oh, there are tons of such things. Like: "writing a complex desktop application" or "writing application with complicated internal structures". E.g.: "firefox", "gcc".
>But, would you write the kernel of an embedded OS for a microcontroller in Java?
These guys even made a credible attempt at that: http://en.wikipedia.org/wiki/Singularity_%28operating_sys...
Quotes of the week Posted Apr 23, 2012 6:48 UTC (Mon) by khim (subscriber, #9252) [Link] That's a very simple example, but things like this happen all the time in complex _desktop_ applications where speed is most important. Yup. And this is exactly where you can compare results of GC-based approach and non-GC-based approach. Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010). You may explain that white is blue till you face is blue but I have my own eyes, you know. These guys even made a credible attempt at that: http://en.wikipedia.org/wiki/Singularity_(operating_system) These guys burned nice chunk of Microsoft's cash for the pointless exercise, I'll grant you that. From your own link: The project appears to have been abandoned since then, however, and no code has been accepted since May 16, 2010.
Quotes of the week Posted Apr 23, 2012 8:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010).
Yet people prefer MSVS2010 because it has vastly more features than VC6. And since you've mentioned MSVS...
Up until MSVS 2010 it was mostly written in native code. MSVS 2010 had its editor rewritten using WPF (and C#) and for me it works _faster_ than the old editor in MSVS 2008. Besides, the bulk of MSVS is still native code.
>These guys burned nice chunk of Microsoft's cash for the pointless exercise, I'll grant you that. From your own link: The project appears to have been abandoned since then, however, and no code has been accepted since May 16, 2010.
Yes, the project was a success (they've achieved the stated goals) and so they moved on to the next stage: http://en.wikipedia.org/wiki/Midori_%28operating_system%29
Quotes of the week Posted Apr 23, 2012 20:54 UTC (Mon) by khim (subscriber, #9252) [Link] Yes, the project was a success (they've achieved the stated goals) and so they moved on to the next stage: http://en.wikipedia.org/wiki/Midori_%28operating_system%29 Ah, so they want to burn more money and produce nice sister exhibit for the Computer History Museum exhibit. Apparently research is not done till sponsor has any money to pay. Will be interesting to see what they'll actually produce before the project closure.
Quotes of the week Posted Apr 23, 2012 21:13 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's a long-term project (you know, companies actually can plan further than the next quarter). And it's not similar to Amoeba at all.
And speaking of museum exhibits, do you know that Linux is obsolete from the very start and should be in a museum along with all others obsolete monolithic OSes?
Quotes of the week Posted Apr 23, 2012 21:50 UTC (Mon) by khim (subscriber, #9252) [Link] And speaking of museum exhibits, do you know that Linux is obsolete from the very start and should be in a museum along with all others obsolete monolithic OSes? Sure. In dreamland of eggheads it was obsolete before it was even born. In real world it's quite actual and will serve us well till the architecture will remain similar to Von Neumann one. And when it'll finally break apart (right now it's creaking, but stays: we no longer have Von Neumann architecture but we do have an illusion of one) all these managed languages will be put on exhibition in museum near Linux as relicts of the past. Which will be a pity because Linux at least solves real problems while all the creations solve the problems which don't really exist.
Quotes of the week Posted Apr 24, 2012 0:53 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
No, by your logic Linux should have been put directly into museum. After all, a hobbyist/skunkworks project which uses obsolete ideas can't succeed.
It's certainly possible, even quite likely, that Midori won't lead to anything new. However, its successor eventually would. That's the nature of research.
For example, IBM is developing lithium-air batteries that have been in development for more than 30 years. Should the abandon it, since so far it's only been sucking money?
Quotes of the week Posted Apr 23, 2012 8:40 UTC (Mon) by dgm (subscriber, #49227) [Link]
> Programs written in C/C++ are frugal (WRT memory) and fast (things such as uTorrent or MS VC 6.0), programs written in C#/Java are bloated monsters (such as Azureus or MS VC 2010).
There's even a more glaring example: Tomboy vs Gnote. Same design and toolkit, but one uses a garbage collector, and the other is written in C++ with smart pointers.
The applications I see written in Java or C#, or even Python are those that require speed of _development_. The code itself usually does not need to be fast, just fast enough. Trying to run two such programs concurrently is like watching Gamera and Godzilla fighting for machine resources.
Quotes of the week Posted Apr 23, 2012 9:12 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
That's a bad example. I've used both Tomboy and Gnote and I haven't really noticed any difference.
I'm also using a comparable note-taking app on my Android phone, and it's also blazingly fast.
Besides, Mono (still) uses a conservative GC.
Quotes of the week Posted Apr 25, 2012 18:08 UTC (Wed) by massimiliano (subscriber, #3048) [Link] Besides, Mono (still) uses a conservative GC. Not entirely true: the new "sgen" GC is already working very, very well, also in production systems.
Quotes of the week Posted Apr 20, 2012 13:42 UTC (Fri) by jezuch (subscriber, #52988) [Link]
> You can do better with explicit memory management: no need for collection cycles, no need for copying memory around. Just free all the short lived objects at once when no longer needed.
You can do that. But then, after you have accounted for all the corner cases, you have reimplemented half of a garbage collector, badly ;)
Quotes of the week Posted Apr 20, 2012 14:06 UTC (Fri) by renox (subscriber, #23785) [Link]
> But then, after you have accounted for all the corner cases, you have reimplemented half of a garbage collector, badly ;)
Ha! manual allocation has two properties that most GCs don't have:
Quotes of the week Posted Apr 20, 2012 16:04 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>-"real time": time is only spent when you call malloc or free, many GCs can interrupt your software "randomly".
Realtime GCs are certainly possible. http://www.azulsystems.com/ would gladly sell you a system with realtime Java GC suitable for high-frequency trading.
>-swap friendly: as the GC access periodically the objects, it interacts with the swap manager, keeping the objects in memory longer than they ought to be.
That's also possible (in fact, generational GCs are already pretty friendly to swap).
Quotes of the week Posted Apr 20, 2012 19:35 UTC (Fri) by renox (subscriber, #23785) [Link]
Re-read what I said: "most GCs", Azul is only one GC, and an expensive one (IBM sell a realtime GC too).
The only Free realtime GC that I know is SuperCollider's GC.
As for generational GC, no it's not in enough to be swap friendly (in general: I don't know about Azul's properties): see the link below which show that a VM aware GC can be much better: http://lambda-the-ultimate.org/node/2391
The author of this research submitted a patch to the Linux kernel which was rejected..
Quotes of the week Posted Apr 20, 2012 21:28 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
>The only Free realtime GC that I know is SuperCollider's GC.
Oh, there are quite a few of them. But they're unmaintained and/or slow and/or for some obscure academic language.
But ultimately, it's certainly doable. And unlike manual memory management which you have to optimize by hand everywhere, once you have a realtime GC then it can be used for almost all software.
>The author of this research submitted a patch to the Linux kernel which was rejected..
Small wonder. It's ugly as hell and hooks into the lowest VM layers.
Quotes of the week Posted Apr 22, 2012 2:59 UTC (Sun) by dgm (subscriber, #49227) [Link]
> once you have a realtime GC then it can be used for almost all software.
So, what's stopping this wonder from fixing Java and all other garbage collected languages? Maybe it's not the panacea you want to believe it is?
Quotes of the week Posted Apr 22, 2012 3:10 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
It works acceptably fine as it is in the areas it's used.
Java is not really used for desktop apps where low-latency GCs are required. And high-throughput high-latency GCs are generally preferable on servers.
That's also basically the answer to the question: "Why aren't we all using realtime Linux kernel?" And if you really need a realtime GC then there are people who would gladly sell it to you.
Now, there is new research in this area (G1GC in newer SunOracle JDKs). So we're moving in a right direction.
Quotes of the week Posted Apr 20, 2012 9:37 UTC (Fri) by ajf (subscriber, #10844) [Link] In practice, GC'd programs require about 2-3 more times RAM than the same manually-managed programs. Well, if you're referring to this well-known paper, it's actually twice as much RAM not as "manually-managed" memory, but twice as much as the absolute lower bound achieved "by processing heap traces [...] then re-executes the program, invoking free on objects just before they become unreachable". It's a very clever way of measuring the effect of garbage collection (and, as you point out, quantify the time versus space trade-off), but it's not a comparison of GC to manual memory management as it is actually practiced.
Quotes of the week Posted Apr 20, 2012 11:03 UTC (Fri) by dgm (subscriber, #49227) [Link]
With private heaps (arenas?), explicit memory management _can_ also be (and usually is) just a pointer increment.
It's a fairly conventional trick: if you have a situation where memory allocation is a significant part of the time and memory is mostly short-lived (think many temporary objects) you pre-allocate all the memory you need, assign it as is needed, and free it all in one sweep when the operation finishes. This way you avoid wasting time in tracking individual memory blocks.
Quotes of the week Posted Apr 20, 2012 12:16 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
However you have to make sure that ALL objects are not needed. If you accidentally delete an object that's still used - oops.
Quotes of the week Posted Apr 22, 2012 2:52 UTC (Sun) by dgm (subscriber, #49227) [Link]
Nope, you have to make sure you allocate from the arena _only_ those objects that are not going to be used later. It looks like it's the same, but the way you expressed it you will be checking pointers after the fact somehow. The work has to be done beforehand (when writing the code).
And that's not different of how explicit memory management works in all other situations.
|
|||||||||||||