No other (known) malloc implementation randomizes *every* allocation. ElectricFence requires a page (usually 4K) per object. A decent set of test cases is always nice, but many software packages don't have enough. In practice, Valgrind will find errors which manifest themselves every time, but not every time, as the most heinous-to-debug errors tend to do. It looks like DieHard (at least in non-replicated mode) mitigates all of the above problems.
This is exactly what JikesRVM does. It's a (almost completely) Java-in-Java VM implementation. There are certain methods which the compiler knows about and generates assembly which specifically breaks the Java semantics. This is all done in a type-safe manner... there are intrinsic types Address and ObjectReference instead of just using longs.
You can use an O(n) median algorithm to choose a pivot at each step so that the worst case complexity of quicksort is \Theta(n \log n). This adds significant overhead, so nobody does it in practice. Radix sort is not a comparison sort, so it is applicable in fewer situations than quicksort. It assumes something about the input (i.e. limited domain) and uses operations other than simple comparison.
You're simply wrong. Unless you specify it explicitly, JIT compilation is done in the background, so you'll never wait for a method to compile (it will be run in the interpreter). Full-heap GCs can show noticable to annoying pauses, as the parent poster notes.
"Garbage Collection can be very fast. Indeed, there is a much quoted argument that the amortized cost of copying garbage collection tends to zero, as memory tends to infinity. Novice functional programmers often report that on their machines, memory is a constant, not a variable, and this constant has to be uncomfortably large for their programs to run well."
-- Mads Tofte & Jean-Pierre Talpin, 1994
Appel's SML/NJ collector is good, but by no means did it completely solve the GC problem.
You're also free to start your own non-profit association for the advancement and development of open-source/free/whatever operating systems. The FSF and RMS can't do anything to stop you. However, I doubt the EU would take kindly to setting up a competing organization.
Object reuse usually doesn't reduce the load on the garbage collector on modern systems. On the contrary, it may increase the load. This is because modern generational collectors are optimized for reclaiming short-lived objects. Most collectors pay no cost at all for reclaiming them. Reusing objects creates longer-lived objects, which add to the cost of every GC during their lifetime.
This sort of code can cause major performance problems in real code, so it needs to be termed something, and "memory leak" seems to be an appropriate term to overload.
And you ARE finished using that memory. "Live" isn't the same as "reachable". GC approximates liveness (whether or not the memory will be used again in the future).
It is unfortunate that an explicit assign null is required to prevent this though. What can be really fun is if you have a naive optimizing compiler that notices that the assign to null is dead code and takes it out for you.
I've seen a lot of papers relating to escape analysis in Java. I've never seen one that gets a significant improvement in GC performance from stack allocation compared to a generational collector. (Note what I'm saying, because escape analysis can do wonderful things for removing lock/unlock calls in objects that never escape their thread.)
Basically, it seems like allocating on the stack just isn't really cheaper than bump pointer allocation into the nursery. Both spaces also exhibit good locality, so your cache performance is similar. And the stack-allocatable objects don't live that long, so they never get copied out of the nursery, so their reclamation is free.
Not to mention that a heavyweight escape analysis that finds a lot of candidates to stack allocate is generally pretty darned expensive, and that you're compiling Java at runtime, so the user sees the added compilation time.
The "object compounding" you talk about is actually called "object inlining" like you hinted. It's a nifty idea, and you'll probably start seeing a lot more work done on the idea soon in the research community.
It seems like PC^2 is only moderately stable if John Clevinger is setting it up. Though at finals the first time we tried to start it, it crashed the entire X server, which was a lot of fun.
Do you have a 14" or a 12" (the 14s supposedly have longer life because the battery is big enough to offset the larger screen - YMMV)? I've got a 12"/600 and probably get 3 hours if I'm lucky in the same situation. Turning down the LCD brightness helps heaps though.
Besides, even if the halting problem were relevant, the halting problem can be solved in a real computer, which has limited memory and is thus a linear bounded automaton rather than a Turing machine.
Yeah, and I can exactly determine the position and velocity of an electron using only a tube of toothpaste, a can of Pabst Blue Ribbon, and the skull of a housecat. But I don't see any reason to justify my claims either.
Orgasms are only NP-complete in a threesome (3-CNF-SAT). It has been shown that the task can be completed in polynomial time when the conjunction is only between 2 entities (2-CNF-SAT). [see Kama Sutra (translated title: Algorithms) as interpreted by CLRS, exercise 34.4-7]
The actual time spent in the kernel during a context switch seems like it would be only a small part of the penalty you'd pay during a (process-changing) context switch. Switching from one process to another means moving to a different address space, which means that most of the stuff in your caches is going to be trash. The number of cache misses you're going to suffer when the process first starts running again seems like it would be the largest performance problem. This is the main argument for using threads instead of separate processes, not how long they take to create.
Slashdot Mirror
Just remember... Ada WON a DARPA contest.
No other (known) malloc implementation randomizes *every* allocation. ElectricFence requires a page (usually 4K) per object. A decent set of test cases is always nice, but many software packages don't have enough. In practice, Valgrind will find errors which manifest themselves every time, but not every time, as the most heinous-to-debug errors tend to do. It looks like DieHard (at least in non-replicated mode) mitigates all of the above problems.
Yes. What does this have in common? Other than it's software and it has something do do with security or reliability or something?
Buy two disks.
This is exactly what JikesRVM does. It's a (almost completely) Java-in-Java VM implementation. There are certain methods which the compiler knows about and generates assembly which specifically breaks the Java semantics. This is all done in a type-safe manner... there are intrinsic types Address and ObjectReference instead of just using longs.
You can use an O(n) median algorithm to choose a pivot at each step so that the worst case complexity of quicksort is \Theta(n \log n). This adds significant overhead, so nobody does it in practice. Radix sort is not a comparison sort, so it is applicable in fewer situations than quicksort. It assumes something about the input (i.e. limited domain) and uses operations other than simple comparison.
And they don't involve beer.
Dude, as long as I can write in a functional language, I'm all for the drunken coding contest.
Some might say that he's a lunatic with some signs of brilliance.
You're simply wrong. Unless you specify it explicitly, JIT compilation is done in the background, so you'll never wait for a method to compile (it will be run in the interpreter). Full-heap GCs can show noticable to annoying pauses, as the parent poster notes.
"Garbage Collection can be very fast. Indeed, there is a much quoted argument that the amortized cost of copying garbage collection tends to zero, as memory tends to infinity. Novice functional programmers often report that on their machines, memory is a constant, not a variable, and this constant has to be uncomfortably large for their programs to run well."
-- Mads Tofte & Jean-Pierre Talpin, 1994
Appel's SML/NJ collector is good, but by no means did it completely solve the GC problem.
You're also free to start your own non-profit association for the advancement and development of open-source/free/whatever operating systems. The FSF and RMS can't do anything to stop you. However, I doubt the EU would take kindly to setting up a competing organization.
Object reuse usually doesn't reduce the load on the garbage collector on modern systems. On the contrary, it may increase the load. This is because modern generational collectors are optimized for reclaiming short-lived objects. Most collectors pay no cost at all for reclaiming them. Reusing objects creates longer-lived objects, which add to the cost of every GC during their lifetime.
It would also help a lot if it was in Russian instead of English.
This sort of code can cause major performance problems in real code, so it needs to be termed something, and "memory leak" seems to be an appropriate term to overload.
And you ARE finished using that memory. "Live" isn't the same as "reachable". GC approximates liveness (whether or not the memory will be used again in the future).
It is unfortunate that an explicit assign null is required to prevent this though. What can be really fun is if you have a naive optimizing compiler that notices that the assign to null is dead code and takes it out for you.
I've only had it in the bottle, but I didn't find it to be significantly different/better than Duvel. Maybe I should try it on tap.
I've seen a lot of papers relating to escape analysis in Java. I've never seen one that gets a significant improvement in GC performance from stack allocation compared to a generational collector. (Note what I'm saying, because escape analysis can do wonderful things for removing lock/unlock calls in objects that never escape their thread.)
Basically, it seems like allocating on the stack just isn't really cheaper than bump pointer allocation into the nursery. Both spaces also exhibit good locality, so your cache performance is similar. And the stack-allocatable objects don't live that long, so they never get copied out of the nursery, so their reclamation is free.
Not to mention that a heavyweight escape analysis that finds a lot of candidates to stack allocate is generally pretty darned expensive, and that you're compiling Java at runtime, so the user sees the added compilation time.
The "object compounding" you talk about is actually called "object inlining" like you hinted. It's a nifty idea, and you'll probably start seeing a lot more work done on the idea soon in the research community.
It seems like PC^2 is only moderately stable if John Clevinger is setting it up. Though at finals the first time we tried to start it, it crashed the entire X server, which was a lot of fun.
I was wondering why CMU wasn't there this year.
Do you have a 14" or a 12" (the 14s supposedly have longer life because the battery is big enough to offset the larger screen - YMMV)? I've got a 12"/600 and probably get 3 hours if I'm lucky in the same situation. Turning down the LCD brightness helps heaps though.
Yeah, I read this wrong. I read it as "decide halting problem of TM using an LBA" instead of "LBA problem using a TM".
That and I had a compelling desire to use the phrase "skull of a housecat".
Besides, even if the halting problem were relevant, the halting problem can be solved in a real computer, which has limited memory and is thus a linear bounded automaton rather than a Turing machine.
Yeah, and I can exactly determine the position and velocity of an electron using only a tube of toothpaste, a can of Pabst Blue Ribbon, and the skull of a housecat. But I don't see any reason to justify my claims either.
Hmm... iTunes ripped my copy of 100th Window without a hiccup. Is it just certain regions that got the copy protected version? (I'm USA)
Orgasms are only NP-complete in a threesome (3-CNF-SAT). It has been shown that the task can be completed in polynomial time when the conjunction is only between 2 entities (2-CNF-SAT). [see Kama Sutra (translated title: Algorithms) as interpreted by CLRS, exercise 34.4-7]
The correct answer to this question is "An intolerance for stupid questions."
The actual time spent in the kernel during a context switch seems like it would be only a small part of the penalty you'd pay during a (process-changing) context switch. Switching from one process to another means moving to a different address space, which means that most of the stuff in your caches is going to be trash. The number of cache misses you're going to suffer when the process first starts running again seems like it would be the largest performance problem. This is the main argument for using threads instead of separate processes, not how long they take to create.