There is no such thing, in Java, as allocating a chunk of memory.
Right, so when I say
byte b = new byte[10000000];
what is getting allocated, exactly? It looks to me like that would be 10 million bytes of memory, but according to you, apparently it's not. Please enlighten me as to what it is being allocated, exactly, then?
There is no such thing, in Java, as a pointer to memory.
Right. There's only references, which do... what, exactly? How do I get from the b above to the 10 million bytes of memory that I just allocated?
There is a thing called a reference, which may be one of two things: a pointer to a specific object instance (basically a vtable) or null.
*groan*
A vtable is an object that describes a class. It contains pointers to the virtual methods defined by that class, and it has a pointer to the vtable of its superclass (if it has a superclass).
An object contains a pointer to its vtable.
Repeat after me: a reference is a pointer to an object, and an object is an instance of a class. An object that belongs to a class that has virtual methods, needs to have a pointer to the vtable of its class. In Java, all classes have virtual methods, so all objects contain pointers to a vtable. In C++, objects that belong to a class that doesn't have any virtual methods, have no pointers to any vtables.
*sigh*
I don't mind being lectured, but being lectured by someone who doesn't know what he's talking about is... Well, it's amusing, I guess, but it's also a bit sad. So do your homework, dude.
Back on topic, what I was saying is that garbage collection is necessary to prevent one thread within a JVM from being able to peek at memory that has been allocated by another thread. If thread A wants thread B to be able to look at its data, it can pass references to that data to thread B, but the whole point is this: if thread A does not want thread B to be able to look at its data, all it has to do is not pass any references to its data to thread B... but making that secure requires preventing thread B from peeking at anyone else's memory that it hasn't been given any references to, and that requires garbage collection -- or some other way to prevent pointers from pointing at something that they shouldn't be pointing at.
OK, never mind the "bullshit", me never "bothering to do the slightest bit of research", whatever. If *you* had bothered to do even the slightest bit of research before accusing me of talking out of my rear end, you might have stumbled across this little tidbit (which I just found after 2 minutes of googling):
But in terms of doing special things for other languages, there are actually quite a few languages targeted at the Java VM for quite a while. And it actually works pretty well for a wide variety of languages. There are some languages that are very hard to do, like C and C++. And thats mostly because theres no way to do them correctly without creating huge security holes. And thats part of the problem with C and C++. Their naked pointers are just a problem.
Gosling doesn't actually state that the JVM was designed the way it was because of the naked pointer problem, so you may not be convinced by that interview, which took place more than a decade after Java was first released to the public. And, since I didn't think to make a note of the article that mentioned the Java design goals, more than 10 years ago, I can't prove *my* point right now, either. Mea culpa.
Maybe Gosling only realized that "naked pointers" can cause security problems after he designed Java?
The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be. Any Java process running in the same VM would be at risk. This kind of deliberate use of "dangling pointers" is easy to prevent if using garbage collectors, very difficult to prevent otherwise.
Wikipedia mentions a couple ways, tombstones (which I called handles), locks-and-keys (which appears to be slightly inaccurate, but the idea is correct), and a probabilistic allocator. Just build one into the language.
I didn't say it's impossible to avoid dangling pointers without GC, just that it is very difficult.
OK, so it's not "very difficult" -- I concede the point. It is merely "difficult", as in "a lot more involved than simple malloc/free". GC is not the only solution, but the other solutions aren't much better in terms of performance penalties.
FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.
So, even after being careful about memory management in 40 KLOC written by a single person, you still had five memory leaks? And that is easier than GC how? Remember that you have had to develop a method of memory management, that you are not dealing with competing methods of memory management from multiple developers, and that the program is not large. Sorry, but you are not convincing.
Yes, I had 5 memory leaks in 40000 lines of code -- and I found and fixed them all in one afternoon. I thought that wasn't bad, considering it had taken me 6 months to write those 40000 lines to begin with. If you know some way to write code that doesn't have memory leaks at all, I'd be interested to know how you manage that. It's not like using Java, or GC in general, prevents all memory leaks; I have had to deal with that kind of problem too, but I'm always glad to learn.
The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be.
Ridiculous. The only way to allocate dynamic memory from the Java language is by creating objects; there is no way to "hang on to a pointer" because there are no pointers. If you're talking about the JVM itself, then that all depends on the implementation of the VM -- but even still, there is no idea of a pointer unless you're in JNI, in which case you're bypasing the security model anyway...
OK. There are no "pointers" in Java, there are just these things that... somehow... reference objects. Oh, right, now I remember, they're called "references". How stupid of me; I used the wrong word and this totally invalidates my point!
So, let's say I do this:
byte[] b = new byte[100000000];
free(b);
OK, I know there is no "free()" in Java, but that's kinda the point.
What would happen if I were to dereference b after having freed that large array? What memory would it point to, oops, excuse me, what memory would dereferencing b cause to be read or written to?
It's a real honor to be sneered at by someone with a 4-digit slashdot ID who clearly has no fscking clue what he's going on about. Good day to you, sir!:-)
finalize() doesn't deallocate objects. The GC calls finalize() on an object when it discovers that the object is no longer reachable; it deallocates the object sometime after finalize() returns.
Note that it is possible for finalize() to make an object reachable again, e.g. by adding itself to a still-reachable ArrayList. The GC will not deallocate the object in that case; it will wait until the object becomes unreachable again before doing so. It won't call finalize() again, though.
The idea behind finalize() is to give objects a chance to free non-memory resources, e.g. native windows or file descriptors, before being freed themselves. The problem with this is that you might run out of those resources *before* running out of memory, and then you'd be stuck until the GC runs again. This is why standard Java classes that use native non-memory resources, like JFrame or FileInputStream, have methods to explicitly release such resources (dispose() and close(), respectively). Relying on finalize() is almost always a bad idea.
The problems with large projects with many developers, affect GC environments as well. I once had a lot of fun (not!) trying to debug memory leaks in a Java application, that turned out to be caused by Java libraries that did not release references correctly in some cases -- references to application objects, created outside the library. So, I ended up debugging the libraries rather than debugging *my* code.
Any large project is prone to this kind of thing, and your only defenses are documenting ownership in all APIs (even internal ones), testing using memory analyzers, and, perhaps most importantly, regular and thorough code reviews. Unfortunately, in most places where I've worked, code reviews are either sloppy affairs where the senior devs who could potentially contribute just make some obvious criticisms about indentation and naming conventions, or else they simply don't happen at all... which makes it hard for the junior devs to learn how to do their job better.
True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak..
As long as there are no references to the object the GC will reclaim the memory in that map. (see java.lang.ref.Reference and all the subclasses)
The problem I was thinking about occurs when the map in question has a much longer lifetime than the objects it contains. For example, a multi-window application may implement a Windows menu by maintaining a map, that maps window names to window instances; the map's key set would be used to build the window menu, and the map itself would live for the application's entire lifetime. Now, unless you remove windows from the map when you dispose them, you'll have a memory leak.
It's usually not hard to get this kind of thing right, but you do have to write code to make it work correctly; the GC will not prevent this kind of leak. Using a WeakHashMap can often help, but still, you'd have to remember where to use WeakHashMaps and where to use the regular kind, which requires thinking about object ownership... and my original point, a couple of posts back, was that once you have a clear picture of how object ownership should be managed in your app, you won't find it very difficult to use explicit memory management correctly, either. That said, GC does undeniably require you to write *less* code, so I wouldn't argue that GC is a Bad Thing -- just something you should not blindly trust to prevent all memory leaks.
That would be JNI, the Java Native Interface. Depending on the security manager used by a JVM, this hole can be plugged, if that level of paranoia is deemed necessary. Typically, a stand-alone JVM will permit calling native code, but a JVM that is set up to dynamically load code from potentially untrusted sources (like a Java application server, or an embedded JVM in a web browser) will not.
I hear you can marshal Java data for use by C libraries and vice versa. I'd expect a hole there where you could get the contents of a pointer.
There's no hole; when marshalling a compound object, the actual bits of the pointers aren't marshalled, the objects they point to are. Marshalling the bits of a pointer would be pointless (no pun intended) because they wouldn't mean anything to the receiver.
Clearly Java debuggers can get the contents of pointers
They can't, and they don't need to; all a debugger needs to be able to do is dereference pointers.
Is there no way to copy the bitwise contents of a pointer into an int in Java, then later copy it back?
No.
I find it unrealistic to think that you could prevent deliberate "dangling pointers". That kind of security is what hardware-level memory management is about.
...and the Java security just does what it takes to provide that kind of security on devices where hardware memory management is not available.
Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up, and get a memeory leak every few thousand lines of code.
True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak... Which is why using a memory analyzer is a good idea *even* in GC environments.
The G1 collector is still a "work in progress" so they are suggesting that you use it *in production* only if you have a support contract with Sun (Oracle?).
No. The release notes say:
Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.
So it's "not permitted" if you don't have a support contract. That's not the same as "suggesting" you not use it.
The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be. Any Java process running in the same VM would be at risk. This kind of deliberate use of "dangling pointers" is easy to prevent if using garbage collectors, very difficult to prevent otherwise.
Protecting processes running in the same VM from each other may not seem terribly useful now, but Java was originally designed to be used in embedded controllers, where the JVM would *be* the operating system, and where processes had to be protected from each other without the help of a hardware memory management unit.
FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.
Now that news can freely travel across the country and the world, there's no need for every paper to have Washington bureau and foreign correspondents, and consolidation is much needed there.
Careful with that logic! Having multiple reporters chasing the same stories can be a very good thing -- it makes it harder to get away with lying, and makes it more likely that obscure facts get discovered.
I had a similar experience when I was 11 years old. Several acts of vandalism were committed at my school (bike tires punctured) and someone accused me of doing it. (I hadn't.) Pretty soon about half a dozen kids from my class were pointing the finger at me, claiming they'd seen me do it. So, I was found guilty in the court of public opinion, as they say. Luckily our class teacher was a bit more level-headed, realized that there was no evidence and besides, the class ganging up on the scrawny kid that always gets picked on anyway is itself a bit suspicious, but this accusation followed me around for a long time anyway.
Whether it was just that one particularly scary episode, or my history of being bullied for years (I was small for my age, wore glasses, and was the best of my class at everything except sports -- you do the math), I don't know, but eventually I also ended up lonely and paranoid, always expecting the worst from people, e.g. I send someone and email and don't hear back the same day, and I immediately worry that they're angry at me and giving me the silent treatment. That sort of thing.
I have gotten over it to a large extent, partly by indulging my frustration by just spending endless evenings by myself, on my couch, getting drunk, on an almost daily basis, for years. I don't recommend the alcohol part -- while it feels good, it is very bad for your health! Still, I was able to work through a lot of that stuff, and slowly (very slowly) regained my self-respect.
The trauma will never go away entirely; once you've experienced cold-hearted cruelty, you've experienced something most people never will, and it destroys some or all of your innocent cheerfulness and spontaneity. The paranoid thoughts will come back from time to time. But, it is possible to return to leading a good, happy life; I can honestly say I am a happy person again. It just takes me a bit more courage to do some things than other people, but even that gets easier with time.
Maybe a shrink would have been able to help me through my bitterness phase more quickly and with less liver damage. I don't trust shrinks, but I could be wrong about that of course; I wouldn't necessarily pooh-pooh the idea of qualifying bitterness as a disorder. Just because it's less bizarre than schizophrenia doesn't mean it isn't potentially serious.
My brother and me and the other kids on the block played cowboys and Indians sometimes, we shot at each other with toy guns and (weak!) slingshots.
Years later, I amused myself with computer games, including a fair number of first-person shooters. Spent many an enjoyable hour playing Descent and Quake 3. Descent with the PC hooked up to my stereo was awesome -- those fireballs on the screen looked pretty damn good, and, by God, the booming from the speakers was way cool.
I'm 44 now and haven't killed anyone yet, but who knows, eh, what kind of violent rage was set into motion by all that mock fighting, only waiting to turn me into a murderous monster like that kid in Winnenden, Germany? OMG, I'm a ticking time bomb!
Someone has done the research: California's lack of non-compete agreements helped them become a center of technology in the US. Massachusetts' non-compete agreements helped ensure that no tech company prospered there.
I'd love to see that research, and how they managed to prove that it wasn't California's nicer weather that caused techies to prefer it over the Northeast.
The 8088 was a technical nightmare with a crappy architecture . It just got lucky. IBM's justifiable preference was Motorola's infinitely superior 68000. Unfortunately, the 68000 was 9 months to a year away form production and the 8088 was in production 'now'. IBM felt that it had do it 'now' or miss the market window, so they (reluctantly) went with the 8088.
The 8088 was a big step forward compared to the 8080, 8085, and Z80, which were the dominant CPUs for "personal computers" in the late '70s and early '80s. The 8088 could address one megabyte of memory without needing any external bank-switching hardware, and it had 16-bit registers throughout, and it could run at higher clocks than the aforementioned 8-bit CPUs of the time. Compared to the 64 kilobyte address space of the 8080/8085/Z80 and the 6502, this was a big improvement, and, as lame as it may sound today, a CPU with 16-bit registers and a 4.77 MHz clock was pretty fast compared to what existed in personal computers at the time.
The 8088 really was a significant improvement. Yes, the 68000 was better, but it wasn't available in quantity yet, but perhaps even more importantly, choosing the x86 for the PC meant that software like WordStar and DBase and others, which was written in 8080 assembly language, could be ported to the new platform relatively easily. Porting 8080 code to the 68000 means rewriting everything; porting that same code to the x86 at least makes it possible to reuse some code -- because the x86 assembler can grok 8080 assembly language. Yes, you have to deal with the x86 segmented memory model, and with the differences between the CP/M system calls and those of MS-DOS, but those chores are still a lot less onerous than having to rewrite *everything*.
Neither Intel nor Microsoft "got lucky" when IBM defined the PC architecture. Those were the technologies that made the most sense at the time.
What rock have you been living under? The linked rant/article is from 1992! Contrary to what it says, the limitations of the 8088 architecture *were* overcome by the 386, but that article was written before DOS extenders allowing protected-mode applications became common, never mind Windows adding protected-mode support. The Windows world has had a flat address space for many years now, and the segmented aspects of x86 are only supported for non-performance-critical legacy code.
People are always talking about colonizing Mars like you can compare it to Europeans colonizing America 400 years ago.
It's not going to happen. Colonizing America was easy: first, go there -- a few weeks on a large sailing ship, proven technology -- not without danger, sure, but even so, pretty much routine. Europeans had been sailing large ship across long distances for centuries.
Once they were there, they had to somehow deal with the natives; that didn't always work out, but often enough it did. And finally, they had to make a living. No problems there; it's still planet Earth; the climate is a bit different from England, different crops thrive there, etc., but really, it's not *that* different.
Now, let's go to Mars. Atmospheric pressure is about 1% of what it is on Earth, and it's mostly carbon dioxide. If you like going for walks in the fresh air, don't go to Mars, because you'll never be able to go outside without a spacesuit. You think a leaky roof or a broken heater on Earth is a problem? Try living somewhere where a leaky roof will cause everybody in the house to suffocate. Oh, and where are you going to grow your crops? Outside?
Maybe all of those challenges can be mastered, but I'm not holding my breath. I'd like to see someone establish a self-sufficient colony on Antarctica first, and even that is an easy environment compared to Mars.
I grew up on sci-fi like all good slashdotters, but I'd like to see us deal with our problems on Earth a bit better before we start pumping billions into some impractical space colony pipe dream.
Adopt a policy that 'dangerous driving, not speed, kills' and enforce it as such. I've seen more highway accidents that were caused by police than I thought was possible.
Why? In the US, it is not a fun thing to see a cop car pretty much ever. You could be doing 50 in a 55 mph zone and you would instinctively want to press on your brakes when you see a cop on the side of the road, then for a few seconds, you will look at your speedometer, check your mirrors, and generally be on edge.
What weren't you doing for those few seconds?
Paying attention to the road and other cars.
That scenario does not describe accidents being caused by police, it describes people overreacting to the sight of police cars.
I see this too, almost every day, and it really puzzles me. I'm from Europe and have lived in the U.S. for almost 9 years now, and U.S. highway cops have a pretty bad reputation on the other side of the pond, but speaking from my own experience, I got pulled over twice in those nine years, once for dangerous driving (I was weaving with way too little margin for error) and once for speeding (going 80 mph in a 65 mph zone). On the first occasion, I received a warning; on the second, the cop gave me a ticket for a lesser offense (seatbelt) that wouldn't cause my insurance premium to go up.
I've found the police here pretty reasonable so far, but apart from that, why do people slow down when they see a police car with blinking lights by the side of the road? He's already busy writing someone else a ticket; do you really think he's going to drop that and come after you instead, for doing 70 mph in a 65 mph zone? Jeez, relax already!
Here is something your smart ass probably didn't know: if you have no access to a gun you can still kill someone! Wow, what a shocker!
Thank you for pointing that out. You're absolutely right; I had no idea that it is possible to kill someone without having access to a gun.
Still curious how banning handguns would cause the rate of handgun homicides to increase. Please feel free to enlighten my not-so-smart ass.
What were the handgun-related homicides before putting bans in place? It's not a comparison of USA versus Europe, but of europe pre-ban to Europe post-ban. After all, many lawless countries have anti-firearm laws on the books-- if you want to play with red herrings.
Feel free to stop speculating and start posting some actual statistics. Something that would actually back up the "This leads to the unexpected result of handgun murders going up after handguns are banned" comment that I was responding to in the first place.
I guess you're suggesting that Europe was even safer before banning/regulating handguns? I'm open-minded, but unsubstantiated claims like the above are not terribly convincing on their own.
The Microsoft tax isn't that big a deal, at least not in the Thinkpad price range. Were their Linux-based laptops any cheaper? I know some other companies that offer Linux don't offer any discount for it.
They were cheaper. I bought a T61 a few months ago, mail order straight from Lenovo, and I went for the Linux option. I saved about $120 that way.
I do admit that I didn't try the route of buying the Microsoft option and then trying to get a refund. Maybe that have worked out to an even lower end price, but at what cost in terms of hassle?
Given that I was going to configure the machine for Linux/Windows dual boot anyway, as I have done with all my PCs for more than a decade, Lenovo's option was a double win: one, I didn't spend any money on an OS for which I already own a license anyway; I simply shrank the Linux partition and installed XP from a retail CD. And two, I didn't have to spend countless hours struggling to get pesky stuff like X and WiFi to work under Linux.
I was sad to see Lenovo ditch their 4:3 (specifically, 1400x1050) screens from the T-series lineup, and now I'm even sadder that they are reinstating the mandatory Microsoft tax.
Why is it that every single rover image, has an R, G, and B hump in an entirely different range? Every single image.
Because the rover is on a different planet, with different lighting conditions, different atmosphere, different everything?
I have looked at thousands of histograms, and I have never seen this pattern anywhere else. I can easily reproduce the effect of course, but never have I ever seen the typical bell-curve of a histogram be consistently different in each channel, image after image, EXCEPT with NASA Mars images, in normal images.
You have never seen this pattern anywhere else? What exactly are you comparing it to?
It is particularly obvious in this image because of the blow-out in the channels (the vertical columns on the right of the hump in each histogram). I made another version where I did nothing but adjust the three channels so that that vertical column lines up on all three channels. Not quite as bright, but probably more accurate.
Since this camera is, I believe, using a monochrome CCD with filters, that column, present in all three channels, is likely an artifact of the CCD or in the image processing. Since it is the same CCD, with three different filters, those three channels should line up on the column. They should not be in entirely different thirds of the image.
You say that that "blow-out" or "column" is likely an artifact of... whatever.
You also say that the camera is, I believe, using a monochrome CCD with filters, etc... That sounds plausible to me, because from what I've read in the past, that's pretty much standard equipment on unmanned NASA missions... but before you start accusing NASA of messing with their data before releasing it to the public, shouldn't YOU take some time to get your facts straight?
Remove the "likely" from that argument, and and maybe you're on to something.
Slashdot Mirror
There is no such thing, in Java, as allocating a chunk of memory.
Right, so when I say
byte b = new byte[10000000];
what is getting allocated, exactly? It looks to me like that would be 10 million bytes of memory, but according to you, apparently it's not. Please enlighten me as to what it is being allocated, exactly, then?
There is no such thing, in Java, as a pointer to memory.
Right. There's only references, which do... what, exactly? How do I get from the b above to the 10 million bytes of memory that I just allocated?
There is a thing called a reference, which may be one of two things: a pointer to a specific object instance (basically a vtable) or null.
*groan*
A vtable is an object that describes a class. It contains pointers to the virtual methods defined by that class, and it has a pointer to the vtable of its superclass (if it has a superclass).
An object contains a pointer to its vtable.
Repeat after me: a reference is a pointer to an object, and an object is an instance of a class. An object that belongs to a class that has virtual methods, needs to have a pointer to the vtable of its class. In Java, all classes have virtual methods, so all objects contain pointers to a vtable. In C++, objects that belong to a class that doesn't have any virtual methods, have no pointers to any vtables.
*sigh*
I don't mind being lectured, but being lectured by someone who doesn't know what he's talking about is... Well, it's amusing, I guess, but it's also a bit sad. So do your homework, dude.
Back on topic, what I was saying is that garbage collection is necessary to prevent one thread within a JVM from being able to peek at memory that has been allocated by another thread. If thread A wants thread B to be able to look at its data, it can pass references to that data to thread B, but the whole point is this: if thread A does not want thread B to be able to look at its data, all it has to do is not pass any references to its data to thread B... but making that secure requires preventing thread B from peeking at anyone else's memory that it hasn't been given any references to, and that requires garbage collection -- or some other way to prevent pointers from pointing at something that they shouldn't be pointing at.
But in terms of doing special things for other languages, there are actually quite a few languages targeted at the Java VM for quite a while. And it actually works pretty well for a wide variety of languages. There are some languages that are very hard to do, like C and C++. And thats mostly because theres no way to do them correctly without creating huge security holes. And thats part of the problem with C and C++. Their naked pointers are just a problem.
See here.
Gosling doesn't actually state that the JVM was designed the way it was because of the naked pointer problem, so you may not be convinced by that interview, which took place more than a decade after Java was first released to the public. And, since I didn't think to make a note of the article that mentioned the Java design goals, more than 10 years ago, I can't prove *my* point right now, either. Mea culpa.
Maybe Gosling only realized that "naked pointers" can cause security problems after he designed Java?
Whatever...
The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be. Any Java process running in the same VM would be at risk. This kind of deliberate use of "dangling pointers" is easy to prevent if using garbage collectors, very difficult to prevent otherwise.
Wikipedia mentions a couple ways, tombstones (which I called handles), locks-and-keys (which appears to be slightly inaccurate, but the idea is correct), and a probabilistic allocator. Just build one into the language.
I didn't say it's impossible to avoid dangling pointers without GC, just that it is very difficult.
OK, so it's not "very difficult" -- I concede the point. It is merely "difficult", as in "a lot more involved than simple malloc/free". GC is not the only solution, but the other solutions aren't much better in terms of performance penalties.
FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.
So, even after being careful about memory management in 40 KLOC written by a single person, you still had five memory leaks? And that is easier than GC how? Remember that you have had to develop a method of memory management, that you are not dealing with competing methods of memory management from multiple developers, and that the program is not large. Sorry, but you are not convincing.
Yes, I had 5 memory leaks in 40000 lines of code -- and I found and fixed them all in one afternoon. I thought that wasn't bad, considering it had taken me 6 months to write those 40000 lines to begin with. If you know some way to write code that doesn't have memory leaks at all, I'd be interested to know how you manage that. It's not like using Java, or GC in general, prevents all memory leaks; I have had to deal with that kind of problem too, but I'm always glad to learn.
The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be.
Ridiculous. The only way to allocate dynamic memory from the Java language is by creating objects; there is no way to "hang on to a pointer" because there are no pointers. If you're talking about the JVM itself, then that all depends on the implementation of the VM -- but even still, there is no idea of a pointer unless you're in JNI, in which case you're bypasing the security model anyway...
OK. There are no "pointers" in Java, there are just these things that... somehow... reference objects. Oh, right, now I remember, they're called "references". How stupid of me; I used the wrong word and this totally invalidates my point!
So, let's say I do this:
OK, I know there is no "free()" in Java, but that's kinda the point.
What would happen if I were to dereference b after having freed that large array? What memory would it point to, oops, excuse me, what memory would dereferencing b cause to be read or written to?
It's a real honor to be sneered at by someone with a 4-digit slashdot ID who clearly has no fscking clue what he's going on about. Good day to you, sir! :-)
Note that it is possible for finalize() to make an object reachable again, e.g. by adding itself to a still-reachable ArrayList. The GC will not deallocate the object in that case; it will wait until the object becomes unreachable again before doing so. It won't call finalize() again, though.
The idea behind finalize() is to give objects a chance to free non-memory resources, e.g. native windows or file descriptors, before being freed themselves. The problem with this is that you might run out of those resources *before* running out of memory, and then you'd be stuck until the GC runs again. This is why standard Java classes that use native non-memory resources, like JFrame or FileInputStream, have methods to explicitly release such resources (dispose() and close(), respectively). Relying on finalize() is almost always a bad idea.
See the Object.finalize() javadoc.
Any large project is prone to this kind of thing, and your only defenses are documenting ownership in all APIs (even internal ones), testing using memory analyzers, and, perhaps most importantly, regular and thorough code reviews. Unfortunately, in most places where I've worked, code reviews are either sloppy affairs where the senior devs who could potentially contribute just make some obvious criticisms about indentation and naming conventions, or else they simply don't happen at all... which makes it hard for the junior devs to learn how to do their job better.
True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak..
As long as there are no references to the object the GC will reclaim the memory in that map. (see java.lang.ref.Reference and all the subclasses)
The problem I was thinking about occurs when the map in question has a much longer lifetime than the objects it contains. For example, a multi-window application may implement a Windows menu by maintaining a map, that maps window names to window instances; the map's key set would be used to build the window menu, and the map itself would live for the application's entire lifetime. Now, unless you remove windows from the map when you dispose them, you'll have a memory leak.
It's usually not hard to get this kind of thing right, but you do have to write code to make it work correctly; the GC will not prevent this kind of leak. Using a WeakHashMap can often help, but still, you'd have to remember where to use WeakHashMaps and where to use the regular kind, which requires thinking about object ownership... and my original point, a couple of posts back, was that once you have a clear picture of how object ownership should be managed in your app, you won't find it very difficult to use explicit memory management correctly, either. That said, GC does undeniably require you to write *less* code, so I wouldn't argue that GC is a Bad Thing -- just something you should not blindly trust to prevent all memory leaks.
That would be JNI, the Java Native Interface. Depending on the security manager used by a JVM, this hole can be plugged, if that level of paranoia is deemed necessary. Typically, a stand-alone JVM will permit calling native code, but a JVM that is set up to dynamically load code from potentially untrusted sources (like a Java application server, or an embedded JVM in a web browser) will not.
I hear you can marshal Java data for use by C libraries and vice versa. I'd expect a hole there where you could get the contents of a pointer.
There's no hole; when marshalling a compound object, the actual bits of the pointers aren't marshalled, the objects they point to are. Marshalling the bits of a pointer would be pointless (no pun intended) because they wouldn't mean anything to the receiver.
Clearly Java debuggers can get the contents of pointers
They can't, and they don't need to; all a debugger needs to be able to do is dereference pointers.
Is there no way to copy the bitwise contents of a pointer into an int in Java, then later copy it back?
No.
I find it unrealistic to think that you could prevent deliberate "dangling pointers". That kind of security is what hardware-level memory management is about.
...and the Java security just does what it takes to provide that kind of security on devices where hardware memory management is not available.
Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up, and get a memeory leak every few thousand lines of code.
True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak... Which is why using a memory analyzer is a good idea *even* in GC environments.
The G1 collector is still a "work in progress" so they are suggesting that you use it *in production* only if you have a support contract with Sun (Oracle?).
No. The release notes say:
Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.
So it's "not permitted" if you don't have a support contract. That's not the same as "suggesting" you not use it.
Protecting processes running in the same VM from each other may not seem terribly useful now, but Java was originally designed to be used in embedded controllers, where the JVM would *be* the operating system, and where processes had to be protected from each other without the help of a hardware memory management unit.
FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.
Now that news can freely travel across the country and the world, there's no need for every paper to have Washington bureau and foreign correspondents, and consolidation is much needed there.
Careful with that logic! Having multiple reporters chasing the same stories can be a very good thing -- it makes it harder to get away with lying, and makes it more likely that obscure facts get discovered.
Whether it was just that one particularly scary episode, or my history of being bullied for years (I was small for my age, wore glasses, and was the best of my class at everything except sports -- you do the math), I don't know, but eventually I also ended up lonely and paranoid, always expecting the worst from people, e.g. I send someone and email and don't hear back the same day, and I immediately worry that they're angry at me and giving me the silent treatment. That sort of thing. I have gotten over it to a large extent, partly by indulging my frustration by just spending endless evenings by myself, on my couch, getting drunk, on an almost daily basis, for years. I don't recommend the alcohol part -- while it feels good, it is very bad for your health! Still, I was able to work through a lot of that stuff, and slowly (very slowly) regained my self-respect.
The trauma will never go away entirely; once you've experienced cold-hearted cruelty, you've experienced something most people never will, and it destroys some or all of your innocent cheerfulness and spontaneity. The paranoid thoughts will come back from time to time. But, it is possible to return to leading a good, happy life; I can honestly say I am a happy person again. It just takes me a bit more courage to do some things than other people, but even that gets easier with time.
Maybe a shrink would have been able to help me through my bitterness phase more quickly and with less liver damage. I don't trust shrinks, but I could be wrong about that of course; I wouldn't necessarily pooh-pooh the idea of qualifying bitterness as a disorder. Just because it's less bizarre than schizophrenia doesn't mean it isn't potentially serious.
Years later, I amused myself with computer games, including a fair number of first-person shooters. Spent many an enjoyable hour playing Descent and Quake 3. Descent with the PC hooked up to my stereo was awesome -- those fireballs on the screen looked pretty damn good, and, by God, the booming from the speakers was way cool.
I'm 44 now and haven't killed anyone yet, but who knows, eh, what kind of violent rage was set into motion by all that mock fighting, only waiting to turn me into a murderous monster like that kid in Winnenden, Germany? OMG, I'm a ticking time bomb!
*shakes head in disbelief*
Someone has done the research: California's lack of non-compete agreements helped them become a center of technology in the US. Massachusetts' non-compete agreements helped ensure that no tech company prospered there.
I'd love to see that research, and how they managed to prove that it wasn't California's nicer weather that caused techies to prefer it over the Northeast.
The 8088 was a technical nightmare with a crappy architecture . It just got lucky. IBM's justifiable preference was Motorola's infinitely superior 68000. Unfortunately, the 68000 was 9 months to a year away form production and the 8088 was in production 'now'. IBM felt that it had do it 'now' or miss the market window, so they (reluctantly) went with the 8088.
The 8088 was a big step forward compared to the 8080, 8085, and Z80, which were the dominant CPUs for "personal computers" in the late '70s and early '80s. The 8088 could address one megabyte of memory without needing any external bank-switching hardware, and it had 16-bit registers throughout, and it could run at higher clocks than the aforementioned 8-bit CPUs of the time. Compared to the 64 kilobyte address space of the 8080/8085/Z80 and the 6502, this was a big improvement, and, as lame as it may sound today, a CPU with 16-bit registers and a 4.77 MHz clock was pretty fast compared to what existed in personal computers at the time.
The 8088 really was a significant improvement. Yes, the 68000 was better, but it wasn't available in quantity yet, but perhaps even more importantly, choosing the x86 for the PC meant that software like WordStar and DBase and others, which was written in 8080 assembly language, could be ported to the new platform relatively easily. Porting 8080 code to the 68000 means rewriting everything; porting that same code to the x86 at least makes it possible to reuse some code -- because the x86 assembler can grok 8080 assembly language. Yes, you have to deal with the x86 segmented memory model, and with the differences between the CP/M system calls and those of MS-DOS, but those chores are still a lot less onerous than having to rewrite *everything*.
Neither Intel nor Microsoft "got lucky" when IBM defined the PC architecture. Those were the technologies that made the most sense at the time.
What rock have you been living under? The linked rant/article is from 1992! Contrary to what it says, the limitations of the 8088 architecture *were* overcome by the 386, but that article was written before DOS extenders allowing protected-mode applications became common, never mind Windows adding protected-mode support. The Windows world has had a flat address space for many years now, and the segmented aspects of x86 are only supported for non-performance-critical legacy code.
It's not going to happen. Colonizing America was easy: first, go there -- a few weeks on a large sailing ship, proven technology -- not without danger, sure, but even so, pretty much routine. Europeans had been sailing large ship across long distances for centuries.
Once they were there, they had to somehow deal with the natives; that didn't always work out, but often enough it did. And finally, they had to make a living. No problems there; it's still planet Earth; the climate is a bit different from England, different crops thrive there, etc., but really, it's not *that* different.
Now, let's go to Mars. Atmospheric pressure is about 1% of what it is on Earth, and it's mostly carbon dioxide. If you like going for walks in the fresh air, don't go to Mars, because you'll never be able to go outside without a spacesuit. You think a leaky roof or a broken heater on Earth is a problem? Try living somewhere where a leaky roof will cause everybody in the house to suffocate. Oh, and where are you going to grow your crops? Outside?
Maybe all of those challenges can be mastered, but I'm not holding my breath. I'd like to see someone establish a self-sufficient colony on Antarctica first, and even that is an easy environment compared to Mars.
I grew up on sci-fi like all good slashdotters, but I'd like to see us deal with our problems on Earth a bit better before we start pumping billions into some impractical space colony pipe dream.
Adopt a policy that 'dangerous driving, not speed, kills' and enforce it as such. I've seen more highway accidents that were caused by police than I thought was possible.
Why? In the US, it is not a fun thing to see a cop car pretty much ever. You could be doing 50 in a 55 mph zone and you would instinctively want to press on your brakes when you see a cop on the side of the road, then for a few seconds, you will look at your speedometer, check your mirrors, and generally be on edge.
What weren't you doing for those few seconds? Paying attention to the road and other cars.
That scenario does not describe accidents being caused by police, it describes people overreacting to the sight of police cars.
I see this too, almost every day, and it really puzzles me. I'm from Europe and have lived in the U.S. for almost 9 years now, and U.S. highway cops have a pretty bad reputation on the other side of the pond, but speaking from my own experience, I got pulled over twice in those nine years, once for dangerous driving (I was weaving with way too little margin for error) and once for speeding (going 80 mph in a 65 mph zone). On the first occasion, I received a warning; on the second, the cop gave me a ticket for a lesser offense (seatbelt) that wouldn't cause my insurance premium to go up. I've found the police here pretty reasonable so far, but apart from that, why do people slow down when they see a police car with blinking lights by the side of the road? He's already busy writing someone else a ticket; do you really think he's going to drop that and come after you instead, for doing 70 mph in a 65 mph zone? Jeez, relax already!
Here is something your smart ass probably didn't know: if you have no access to a gun you can still kill someone! Wow, what a shocker!
Thank you for pointing that out. You're absolutely right; I had no idea that it is possible to kill someone without having access to a gun.
Still curious how banning handguns would cause the rate of handgun homicides to increase. Please feel free to enlighten my not-so-smart ass.
What were the handgun-related homicides before putting bans in place? It's not a comparison of USA versus Europe, but of europe pre-ban to Europe post-ban. After all, many lawless countries have anti-firearm laws on the books-- if you want to play with red herrings.
Feel free to stop speculating and start posting some actual statistics. Something that would actually back up the "This leads to the unexpected result of handgun murders going up after handguns are banned" comment that I was responding to in the first place.
I guess you're suggesting that Europe was even safer before banning/regulating handguns? I'm open-minded, but unsubstantiated claims like the above are not terribly convincing on their own.
This leads to the unexpected result of handgun murders going up after handguns are banned.
I guess that explains why there are so many more handgun homicides in Europe than in the U.S... Oh, wait.
The Microsoft tax isn't that big a deal, at least not in the Thinkpad price range. Were their Linux-based laptops any cheaper? I know some other companies that offer Linux don't offer any discount for it.
They were cheaper. I bought a T61 a few months ago, mail order straight from Lenovo, and I went for the Linux option. I saved about $120 that way.
I do admit that I didn't try the route of buying the Microsoft option and then trying to get a refund. Maybe that have worked out to an even lower end price, but at what cost in terms of hassle?
Given that I was going to configure the machine for Linux/Windows dual boot anyway, as I have done with all my PCs for more than a decade, Lenovo's option was a double win: one, I didn't spend any money on an OS for which I already own a license anyway; I simply shrank the Linux partition and installed XP from a retail CD. And two, I didn't have to spend countless hours struggling to get pesky stuff like X and WiFi to work under Linux.
I was sad to see Lenovo ditch their 4:3 (specifically, 1400x1050) screens from the T-series lineup, and now I'm even sadder that they are reinstating the mandatory Microsoft tax.
Why is it that every single rover image, has an R, G, and B hump in an entirely different range? Every single image.
Because the rover is on a different planet, with different lighting conditions, different atmosphere, different everything?
I have looked at thousands of histograms, and I have never seen this pattern anywhere else. I can easily reproduce the effect of course, but never have I ever seen the typical bell-curve of a histogram be consistently different in each channel, image after image, EXCEPT with NASA Mars images, in normal images.
You have never seen this pattern anywhere else? What exactly are you comparing it to?
It is particularly obvious in this image because of the blow-out in the channels (the vertical columns on the right of the hump in each histogram). I made another version where I did nothing but adjust the three channels so that that vertical column lines up on all three channels. Not quite as bright, but probably more accurate. Since this camera is, I believe, using a monochrome CCD with filters, that column, present in all three channels, is likely an artifact of the CCD or in the image processing. Since it is the same CCD, with three different filters, those three channels should line up on the column. They should not be in entirely different thirds of the image.
You say that that "blow-out" or "column" is likely an artifact of... whatever.
You also say that the camera is, I believe, using a monochrome CCD with filters, etc... That sounds plausible to me, because from what I've read in the past, that's pretty much standard equipment on unmanned NASA missions... but before you start accusing NASA of messing with their data before releasing it to the public, shouldn't YOU take some time to get your facts straight?
Remove the "likely" from that argument, and and maybe you're on to something.