- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Write-only memory? Well, that must be useful.
Admin
Double bah! Real programmers started with a 1K ZX-81, and used machine code! <grin>
Admin
On old 8-bit computers, with their tiny 64K address space, it was not at all unusual for some memory locations to be, in a sense, overloaded. You'd write to a location to set some hardware state, and read from it to retrieve some completely unrelated value.
Admin
"Most of them are not that well versed with what is going on besides what they actually know." OK, as opposed to the other kind that is well versed with what they don't actually know?
Sorry, after 20 years of working with all experience ranges, I have seen only at most a slight correlation of oldness of school with willingness to consider the solutions of others. Everyone's opinionated to some degree.
I'll agree that everyone needs to work at keeping up with what's going on. C# and Java programming (my current work) are quite different from programming 6502 machine language in the 1K provided on a KIM-1 (my first machine).
Admin
This is what I was going to say.
Admin
Right here. The winner.
Admin
two 7-track tape drives. . .
Admin
Afaicr, the C64 had a number of I/O mapped memory that could only be POKEd*, not PEEKed*. Most of the SID* was like that. The VIC* had memory locations that when written specified requested behaviour, while when read would tell the status, e.g. the current raster line.
*POKE: The BASIC instruction for storing an 8-bit value in a specific memory address. *PEEK: The BASIC instruction for reading an 8-bit memory location. *SID: The sound controller chip. *VIC: The video controller chip.
Wow! A blast from the past!
Admin
/dev/null
There is tons of it there.
Admin
Actually, we started with 4-bit words
Admin
At Signetics, apparently.
http://en.wikipedia.org/wiki/Write_only_memory
I also seem to recall W.O.M. being a plot point in a David Brin novel.
Admin
Hunt the Wumpus!!
Admin
If the stack is an issue, a StackOverflowException is likely to be the problem rather than an OutOfMemoryException. The stack is usually tiny.
Creating and destroying temporary objects is something Java does very efficiently, using a thread-local "eden" which is easy to wipe. Different Java versions vary, and it could hypothetically be the issue. However, since lots of temporary objects has always been the recommended programming style, it's something Sun has always been careful about. And again, it's unlikely to cause an OutOfMemoryException, since the garbage collector attempts to run before calling that exception.
(On the other hand, if huge temporary objects are constructed recursively, that could cause all sorts of OutOfMemoryExceptions.)
The most likely issue is with cached data being held too long. And in that case, static methods could be a problem rather than the solution, if it means static references to data that used to be garbage collected.
I've had similar issues, since I work on a memory-hungry web application. The difference, though, is that the memory usage is intentional, as we store huge sections of a database in memory for on-the-fly statistical analysis and other SQL-hostile queries.
Admin
As far as I can tell, the suggestion is that it wasn't leaking memory, it just needed more than 512 for what it was doing. It's like spending hours squeezing every article of clothing into a suitcase, using complicated folding techniques, when you could just get a larger suitcase for ten bucks. If it was leaking, then fixing the leaks is surely more important than getting the normal running memory usage down, especially as that's likely to make your code unmaintainable.
Admin
Wow, he actually managed to get that through management AND produce fixed code? Wilhelm should get a medal and a carte blanche to walk into any software company to start kicking their rear-ends! (Yes, I mean you Adobe!)
Admin
Hey watch it. I wrote a bitchin side-scroller for my C64 in machine code.
Took me ages to copy out all those DATA lines from Zzap64 magazine...
Admin
Actually, we started with ferric rings.
Admin
My recet application takes 500 megs to start. Why? No idea. It caches data records, but with 0 records, it uses up 500 megs of ram. Could I improve it? Sure, but how long will that take? 5 months with a team of 5 perhaps? Or should I just plunk in a $60 memory chip and leave it be? As said, it caches data records. Each record is about 50k in size. I could probably improve that as well, but should I? It currently handles 5'000 records. 750 megs of ram. We're expecting that to grow to 30'000 by 2010. 2 gigs of ram! And I'm out again. Guess I should have improved it when I had the chance. Or, because it's 2010, another 2 gigs of ram will only cost me $20 (or less, who knows?). DONE! More memory. Expectatios have us hitting 100'000 records by 2015. Uh oh: 5.5 gigs. No good now, hard limit is 4 gigs. Solution: Buy a new box. I'd bet dollars to doughnuts that 8 or 16 gigs of ram going into a box would be no problem by 2012 or so, at a cost of maybe a few thousand. Does any of that solve the underlying problem? No, memory requirement is still far higher than it probably could be, but a cost of a few (even ten or twenty) thousand for a new server is far cheaper than 2 man years of recoding effort.
It is, actually. Microcontrollers often use write-only memory for control flags and output pins. There are actually a lot of uses under the proper definition as well.Admin
Wait, no, we started with null and void, and have come full circle!
Admin
You'll just have to wait until the process dies of its own accord or reboot the machine.
Admin
"Running profilers and stress testing tools they were able to identify trouble modules, unreleased resources, and unclosed connections."
Unrelease resources and unclosed connections sound like leaking memory to me. I could be wrong but that's what I got out of it.
Admin
This WTF reminds me of the Pizza Hut Pizza Mia commercial, in which this guy (Wilhem) works very hard producing a "discount pizza availability chart" in order to try and save his friends some money but this pompous douchebag (Bob) tears it down because he wants to be a tool and pay $5 for Pizza Hut's Pizza Mia deal thing.
Admin
LMAO, classic!
Admin
But it's not good decision making to just compare the cost of improving the system itself against the immediate cost of the quick and dirty fix. Maybe that will be the only cost, but that maybe is the giveaway that you need to take uncertainty into account when choosing the solution. The bottom line is what really matters, but if the expected cost of the quick and dirty fix is higher than the expected cost of the system overhaul (ie, it greatly increases the chance of having to do a significantly more expensive re-haul down the line), then the better choice is to spend the money on an overhaul now to maximize your long term profitability. But too many managers don't seem to know about that sort of analysis (or just don't want to bother with the work required, which is a lot harder than just saying "RAM costs less than five months of work").
Admin
TRWTF is that other solutions were not considered :P Sure a RAM increase may have been only a temporary solution, but it wasn't even considered. The ONLY solution considered was an entire rewrite of code.
If I was in the same situation, and I knew that the rewrite of code was the correct decision, my face would still be red since I didn't research any other options.
Admin
..and subsequently all the dudes die years later of heart disease (Memory Leak, Postponed).
Admin
I wouldn't say that's a good excuse for poor code. I'd also say that your dollar estimates, even for 2015, are way too low. I don't think 2 GB of RAM is going to come down in price THAT much in 7 years. Currently, the price of 2 GB of RAM - at the cheapest place I know of - is about $120 which is a lot more than $20.
Also, in the meantime, your users suffer because the server crashes a lot and when it doesn't crash, it takes forever to load pages. That's a large amount of lost revenue that you could be gathering but aren't because users can't see/click on ads and/or go to competing products.
Admin
Keep in mind that in general when you start a project you can choose from one of these three as a goal and you'll usually get it.
In some rare instances you might get two of the three, but it comes at a severe expense of the one you chose not to take. If you try for too much you get a crappy product all around. Most development shops aim for 1 or 3 because resources are cheap!
"Hey we've got this great new product. It doesn't have the features of the other guy, but we only need 1/10 of the RAM of the other guy."
Admin
TRWTF is why they didnt just: Stave off problems with more memory (IF indeed this would have worked) Fix the memory leaks without splurging 5 months/a large team on it.
Pragmatism allied with... the other thing I dont know the term for.
Admin
The computer had 512MB of ram. What production computer has 512MB?
Wilhelm's solution was one of many. It was the correct way to do it from a University Computer Science department standpoint, but businesses don't operate that way. You don't sink 25 man months into problems with such an unbelievably small scope.
The correct solution would have been to upgrade the production server while bug fixing the memory leaks. It just got taken too far. No suprise from a company that would let this happen in the first place.
Wilhelm was the team leader but still an unfortunate player in all of this. The responsiblity of failure wasn't on his shoulders but on the management of said company. This should have never happened.
Admin
I recall PEEK-ing at memory locations that didn't exist on the ZX81 - not all of it returned zero...
The truth is out there....
Those early ZX80/ZX81/Spectrum manuals (the big chunky spiral bound ones) were some of the best programming books I ever recall reading. But maybe 9-year olds are easy to impress :-) (yeah I am old)
Admin
I learned programming on a 128Kb Apple IIe. And you had to go through HUGE hoops to access that second 64K.
No point to this just wanted to brag.
Admin
Admin
I would posit that it doesn't have to be that way. A lot of developers were taught on languages that are too forgiving and so when they build systems, they are lazy and careless. Management who doesn't understand anything about computers at all is also to blame.
Yes, in the real world you are told to do it fast and who cares about the quality. I work in the real world. I understand it. That doesn't mean we should accept it and act like that's just how it is.
As for the story, the way I read it was that it had real problems and was leaking memory. Throwing more RAM at it would have just delayed the time before it crashed but it still would have been crashing. In this case, rewriting it to be more efficient is the correct choice.
Admin
1 less functr per instance per function moved from instance to static in java
(IIRC all non-static functions are virtual in java and therefore in the vtable)
Admin
Presumably the intern's bright idea never got tested, since they'd already fixed the memory problem.
Hmmmm...
Admin
Are you knocking the Signetics 25120:
http://www.national.com/rap/files/datasheet.pdf
Yes, this was actually published in their databook. I love that it needs 6.3VAC....for the heaters :)
Admin
I'd imagine this is why the intern caught them with their pants down in the meeting.
Should have been able to easily refute the Intern's idea with why it was a horrible idea to postpone a real solution :P Should have crushed that poor Intern's smart ass right there....
Admin
Oh great, Bob's my interviewer now? I guess I'd lock myself in a mall. I know, some day I'll be out of memory and money, and I'll have to comment out the call, but I never had the head for all that bigger picture stuff.
Admin
512MB to run a webpage is SMALL for J2EE?
no i know why i write php... rarely have to up the memory limit over 8mb, and when i do it's because i'm processing a massive amount of data and I want to have it all loaded simultaneously for fast access
Admin
If these 5 guys are salaried employees, then management just saved $60.
Admin
Sorry, but the WTF would be just throwing more memory at the problem, because all that would do is make the time between OOM errors longer. It wouldn't solve the core problem of poor resource management in the system.
Now, from TFA, I would guess there is a big chance that the effort was way overboard, but the core intent was correct: fix the source of the problem.
Throwing more memory at the problem is only yet another duct tape and chicken wire solution.
Admin
Admin
But if you want to sell your software to users, can you really reasonably ignore those "vague and fuzzy numbers"? And it's not how much the user's time is worth to them so much as how much the user's time is worth to you -- in other words, if they think your app is slow and bloated and see a better alternative, how much money are you losing compared to if you had built a better program and they were still doing business with you?
Is all this kind of stuff uncertain, and impossible to precisely quantify? Certainly. But without taking uncertain things into accounts, your business is going to run into trouble the first time it's unlucky enough for something to go wrong (for instance, if your biggest client doesn't upgrade their systems for a while and the app gets so slow on their systems that they decide to find something else). Some people/companies get away with bad design for a very long time. That doesn't make it a sound business practice.
(But, yes, definitely stick the RAM in the box at the start to get it working better while you do the bigger fix. A bandaid is better than a continual bleed! And a fix as drastic as Wilhelm's may have indeed been overkill. But it's usually not wise to just do the minimum fix necessary whenever a problem comes up -- especially when you know there are fairly serious underlying problems.)
Admin
i just bought 2GB of DDR2-800 for $50
Admin
I'll agree, rewriting was the right solution from a developer standpoint, but there are times in real world business where you have to step back and say it'll just cost too much to fix. This, of course, is all under the assumption that memory leaks were, at most, a small part of the problem, if there were any at all. If the problem really was that it was leaking memory like a seive, then the correct solution most definitely involves rewrites. But first, get some more ram into that sucker so it doesn't need to be restarted so often.
Admin
Indeed, if you get into a car accident and are bleeding internally, they should obviously start with aromatherapy candles in the Emergency Room. That's an easier option, we can assess in a few hours what that gained us.
Saves on surgeon salaries, and a favorite of insurance companies everywhere.
Admin
Three pages already and I'm still wondering why no one has mentioned anything about the expected lifespan of the app.
Fixing the memory leaks is still the best solution. But after that, even if the app takes up 1GB of production server memory at peak usage, 2.5GB of ram should be enough to handle the changes in the data volume for its entire lifespan (assuming this is your average enterprise app). No need to go through low level tweaking reserved for embedded devices.
Admin
I have to tend to agree with Wilhelm, given the facts available in the piece.
If there are correctable inefficiencies in the system, then adding memory just temporarily masks the problem.
Furthermore, I see nothing in the story which says that Wilhelm has anything other than something sorely lacking in many organizations -- experience. I mean, it wasn't like his group were being forced to write the applications on punch cards and submit them to the batch mainframe via the hot card reader.
So what if he's not a "fun devil"? As per my last set of exchanges, it strikes me as if perhaps too much emphasis is placed on happy smiling faces. Perhaps his lack of emotionality is simply cultural and no one ever took the trouble to actually get to know him. Some people are simply quiet by nature, which can be misinterpreted as taciturnity.
Not every problem can be necessarily solved by throwing more hardware at it and even if it can be, it may be a situation where budgetary or other constraints may not allow such a solution (memory being sort of the low end of the spectrum). What if you've reached the limit of the hardware's upgradability, for instance, and replacing the system is not feasible.
Admittedly, his rationalization, "...but no web application should ever require more than 500 megs", is a bit specious but his overall methodology seems sound.
It sounds to me as if the programmers under his tutelage may have actually learned something valuable.
Admin
Bah! to you too!
My first personal computer had 3854 BYTES (yes, bytes) of RAM to program in. (Commodore VIC-20).