| |||||||||||||
World-writable memory on Samsung Android phonesWorld-writable memory on Samsung Android phonesPosted Dec 18, 2012 20:28 UTC (Tue) by nix (subscriber, #2304)In reply to: World-writable memory on Samsung Android phones by khim Parent article: World-writable memory on Samsung Android phones I think we're arguing fiercely for the same thing in different words in most areas. However... You're wrong, sorry. There are no guarantees at all in the language specification regarding when the VM will choose to allocate memory on the OS or C library level (nor should there be). Thus, you cannot be sure that anything you choose to do, or not do, in Java will or will not allocate memory on that level, though there are things you can do to roughly influence patterns of allocation and allocation rates. You could perfectly well find that your char[] access caused some VM-internal counter to exceed some threshold and a JIT to be kicked off, which would surely allocate memory on the C library level and quite possibly on the OS level as well. (Indeed, I've seen just this with simple integer additions). So you must define what you mean when you say 'without using additional memory', or you should expect to be misinterpreted.It is impossible to do anything in Java without the possibility that the VM will choose to allocate additional memory on the OS or C library level.Wrong. It's impossible if you use immutable classes like String but quite possible if you'll use char[] instead. If you want to do such transition or not depends on the task in question. A JRE can legitimately start thrashing or run out of OS-level memory (and get killed or throttle itself) while executing nothing on the bytecode level but a loop which adds two numbers together. It's unlikely, but it's possible. And OS-level memory is a form of memory one often cares about running out of, even if you can't control it precisely from the bytecode level or above (though JRE command-line parameters can restrict it to some degree, in some implementations). One also cares about running out of memory on the JRE level, not least so as to avoid running into the artificial limits imposed by those command-line parameters. One also cares about minimizing garbage production rates. These are all different problems, with different solutions and different tradeoffs involved. Yet you just said 'memory' and expected us to tell by telepathy which one you meant. But that depends on what problem you're trying to solve! It's not your problem.It bloody well is my problem if I'm one of the candidates your proposed scheme discriminating against! Indeed it has been my problem for many years. (And I'm not by any means the only person with this problem. It's not incredibly common but it is hardly rare. Yes, most people you'll find applying for jobs in the software community are quite good at interviews -- but that's because those of us who aren't never switch jobs until they become intolerable, and get penalized severely in financial terms for that forced decision.)
(Log in to post comments)
World-writable memory on Samsung Android phones Posted Dec 21, 2012 17:18 UTC (Fri) by khim (subscriber, #9252) [Link] There are no guarantees at all in the language specification regarding when the VM will choose to allocate memory on the OS or C library level (nor should there be). Thus, you cannot be sure that anything you choose to do, or not do, in Java will or will not allocate memory on that level, though there are things you can do to roughly influence patterns of allocation and allocation rates. Right. That's serious problem with Java and that's why I'm not big fun of this crazy language. However if you are Java programmer and you claim if you know how to use the beast then you must know how to use it in real world and not just in the programming contests —and that means you should understand when real-world implementation are likely to need memory and when they tend not to need it. A JRE can legitimately start thrashing or run out of OS-level memory (and get killed or throttle itself) while executing nothing on the bytecode level but a loop which adds two numbers together. Not all JREs do that. Aforementioned JavaCard JRE does not. And this problem is generally way, way, WAY too deep to discuss when we are talking about simple mundane tasks. But if the candidate wants to raise it and spend his valuable time discussing it—who I am to object? Just like with real work: you are free to discuss hypothetical problems with JVM, JRE and Intel's microcode when you are asked to create couple of simple forms, but in the end you must provide code in reasonable time and of reasonable quality or else your are not very useful, right? So you must define what you mean when you say 'without using additional memory', or you should expect to be misinterpreted. Absolutely not. Interview process imitates work process in miniature. Someone who's genius and can solve any problem if you'll manage to formulate it precisely enough but will write code which will destroy your whole project if you'll miss one minute detail is someone who's just to dangerous to have around. Yet you just said 'memory' and expected us to tell by telepathy which one you meant. No telepathy, just common sense. You are correct that the task is not precisely formulated, yes. But that's half of the point! Your co-worker (and thus any good candidate) should catch cases where task is not defined precisely enough but s/he should not exhaust you with bazillion questions. If you need to spend two days to write precise spec for the task which only needs two hours to implement then you are better off without such a co-worker, right. In this particular case the good approximation will be "no additional memory in computer science sense" (that is: you only care about memory explicitly allocated by your program, but don't care about JIT details), but if you can meaningfully offer some other idea—that'll give you bonus points. When someone applies his deep knowledge of JVM, JRE, Linux or any other technology to try to solve the task—that's good, it can only be commended, when someone tried to use the same knowleadge to screwup his coworkers… sorry, this something we don't need here (and I doubt there are companies who would want such behavior). Oh, the second half of the point is the question is the ability to actually code solution for the agreed-upon task. It may be slightly different depending on the discussion, of course.
World-writable memory on Samsung Android phones Posted Dec 21, 2012 22:09 UTC (Fri) by nix (subscriber, #2304) [Link] However if you are Java programmer and you claim if you know how to use the beast then you must know how to use it in real world and not just in the programming contests —and that means you should understand when real-world implementation are likely to need memory and when they tend not to need it.You clearly have no idea how complex modern JVMs are. That's bordering on impossible, particularly with the server-mode JVM: you can never tell when the optimizers will kick in. Interview process imitates work process in miniature. Someone who's genius and can solve any problem if you'll manage to formulate it precisely enough but will write code which will destroy your whole project if you'll miss one minute detail is someone who's just to dangerous to have around.In a work situation, you have context -- you are normally formulating and answering these questions yourself, or if helping someone else you both have a common goal in mind. That context defines the level of problem and solution to aim for (that sort of experience is perhaps the major difference between experienced and inexperienced programmers). In an interview, you have no such context -- substantially more precise questions are thus called for.
World-writable memory on Samsung Android phones Posted Dec 23, 2012 13:30 UTC (Sun) by khim (subscriber, #9252) [Link] You clearly have no idea how complex modern JVMs are. I know enough to hate this abomination (it promises to save development time—but then it sucks debugging time for the reasons you've outlined so well thus I'm not at all sure it's a net win), but that's not the point. That's bordering on impossible, particularly with the server-mode JVM: you can never tell when the optimizers will kick in. And so what? Look, if we want to write any kind of program intended to be used by non-programmer (directly or indirectly) then we need to understand how many resources it'll need. Doubly so if we can expect programmer who tries to break our creation instead (most server software for publicly accessible site). For one simple reason: resources cost money! Depending on our task 1GB of excess memory may be not a big deal (if it's a single instance on a single server) or be huge drag on the resources (if there are 100'000 nodes in use). Or it may be even a deal-breaker if we plan to support smartphones with 512MB memory. If we can't do that for one reason or another then such program and such language can not be ever used in production because you can not predict how and when they'll fail. They can only be used in interactive development process: since failure in this case means human programmer must do something and human is resourceful thus it's probably Ok (if worst comes to worst human can use some other means to reach the same goals). But to give the result to the Joe Average or to run stuff in production you must know how many resources it'll need in which cases. If JVM can not be bound by a reasonable limits then it must be replaced, if Java programmer can not write code which is bound to reasonable limits then he should not be hired. It's as simple as that. "No additional memory" is often an approximation when you program in Java, sure, but that's useful approximation so why not use it? You may showcase your deep knowleadge of Java, JVM and other related things as much as you want but if you refuse to accept simple facts of life as they apply to your work then it just means that In a work situation, you have context -- you are normally formulating and answering these questions yourself, or if helping someone else you both have a common goal in mind. You want to imply that said context suddenly jumps in your head when you first come to work in a new team? Nope: you need to poke around, talk with a team members, understand what goes on here, etc. And you need to balance you inquisitiveness with the fact that team members are busy (or else they will not need a new member if they have lots of spare time). In an interview, you have no such context -- substantially more precise questions are thus called for. Absolutely not. As everyone knows there are only two major requirements for the candidate:
World-writable memory on Samsung Android phones Posted Dec 23, 2012 15:28 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
> we need to understand how many resources it'll need.
This is one area where theory and practice differ.
Yes, you need to have some idea of how many resources it'll need, but that can be a matter of trying to run the resulting program a bunch of times and seeing how it works, it doesn't need to be predeicted from the code.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 19:26 UTC (Mon) by khim (subscriber, #9252) [Link] Yes, you need to have some idea of how many resources it'll need, but that can be a matter of trying to run the resulting program a bunch of times and seeing how it works, it doesn't need to be predeicted from the code. This is good way to fine-tune your requirements, but you need to have rough idea about whether you'll need 1GB, 1TB, or 1PB from the beginning. Before first line of code is written, in fact.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 17:27 UTC (Mon) by paulj (subscriber, #341) [Link]
Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. At least for a programmer. Yes, you can make an analysis of what would be the required amount, but this is just a lower-bound. The JVM has, for good reason, an extra-ordinary level of freedom in what it does. It could vary from doing GCs frequently in order to be as conserving of memory as possible (at cost of performance), to very infrequently and using far far memory than what you anticipated (trading space to gain time/performance).
If I were given a question by an interviewer that led me then to explain these trade-offs in reply, and that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet...
World-writable memory on Samsung Android phones Posted Dec 24, 2012 19:49 UTC (Mon) by khim (subscriber, #9252) [Link] Hmm, it seems to be nix who is stating the simple fact: JVM memory allocation is extremely hard to predict. No. He uses said "simple fact" as an excuse to avoid discussions about real problem. Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And JVM complexity is most certainly no excuse. Sure, it makes said task harder, but so what? It's still a strict requirement. If I were given a question by an interviewer that led me then to explain these trade-offs in reply, If you'll take a look on the initial question you'll see that it has nothing to do with all these complexities. Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous—but ball was in Nix's court. Nix raised JVM-introduced problems with JIT, GC and other horrors. And instead of simple and sensible suggestion to ignore all these problems (good approximation for the first try) he raised them to central position of the task. Well, if you want to discuss these things (instead of limiting our exposure to them by using some rough estimates), then I'm ready to do that, too—but it still does not free your from the need to solve this task. And that interviewer then stamped "No Hire" because I had failed to accept "simple facts of life" simply because of that, then I think I'd be glad to have dodged a bullet... Good for you. Perhaps you'll find a place where people always enunciate all the tasks precisely and unambiguously. Perhaps such places do exist, but I've not seen them. In my experience the ability to refine requirements of the task is half of what I do when I write programs. Often the ability to write the code itself is less important compared to the ability to understand WTH we are trying to create in first place and what kinda trade-offs are there.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 21:27 UTC (Mon) by paulj (subscriber, #341) [Link] Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question. And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Really? :) Sure, question was not 100% correctly defined, sure it needed emends to be unambiguous - but ball was in Nix's court. … In my experience the ability to refine requirements of the task is half of what I do when I write programs. I agree 100% with the latter statement. Refining requirements is critical, it takes time and usually at least several communication roundtrips, if not many more, in working out all the hidden assumptions that each side has. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. But hey, YMMV - whatever works for you. I'm sure at least some of your competitors will be glad to hire at least some of the "No Hires" who you find to be questioning ;).
World-writable memory on Samsung Android phones Posted Dec 26, 2012 17:54 UTC (Wed) by khim (subscriber, #9252) [Link] And you think stamping "No Hire" on the curricula vitae of interviewees who can discuss and show a good understanding of how Java code memory allocation maps to JVM/system level allocation will get you that? Knowledge of JVM/system level allocation are great, but these not a replacement for common sense. Joel said it better then me: Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute. Now, go back and think. Do all these discussions about JIT, system level allocations, etc look like something academic about a problem? Well, that's the problem right there. Now, I'm not saying that nix does not Get Things Done, more likely then not he just does not know how to adjust his knowledge to the situation of the interviewing process where interviewer have 45 minutes to say "Hire" or "No Hire", but well… it's his problem, not mine. I would be sceptical that you will get such people if you stamp "No Hire" on the CVs of people who start exploring technical issues that arise out of ambiguities in questions, and instead hire those who don't, be that out of ignorance or timidity. Well, that's why interviews must be conducted in person (even VC is not a good replacement although it can be used as “last resort” kinda thing). When someone tries to dig “too deep” (and discusses pieces which are not really all that relevant to the task on hand) or “too shallow” (and ignores most corner cases) you can quickly try to resolve the situation before it'll escalate. If someone raises JIT-related concerns then it's not plus or minus by itself! The next step is critical: if person says something like “well, usually these are not a problem on practice, let's forget about them for now” then it's big fat plus (interviewee knows about Leaky Abstractions problem but it knows when not to talk about them), but if person goes on to discuss all these minutiae details and abandons the initial task entirely… it's not a good thing to say the least. It's much harder to do discuss these things on forums like LWN: no visual contact and no 45 minutes restriction.
World-writable memory on Samsung Android phones Posted Dec 24, 2012 22:03 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
> Let me repeat once more: before you can deploy any program (including JVM-based) program you must know what resources said program will need. No excuses. Release managers will just refuse to accept your code if you can not answer this question.
you can repeat it all you want, but in the real world things are not always this rigid or predictable and you are wrong to state it as an absolute. I'd say that most release managers won't even ask you about resources, let alone refuse to accept something without the requirements tightly specified.
A huge number of companies don't measure this sort of thing ahead of time, they throw it up and buy more hardware as needed, only addressing the efficiency (and resource consumption) when the cost of providing enough hardware becomes a problem.
This smacks strongly of premature optimization.
Yes, there are times when the resource utilization really matters, but much of the time it doesn't matter that much, and other pressures (like time to market) matter much more.
World-writable memory on Samsung Android phones Posted Dec 26, 2012 18:20 UTC (Wed) by khim (subscriber, #9252) [Link] I'd say that most release managers won't even ask you about resources, Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process. let alone refuse to accept something without the requirements tightly specified. Who said anything about "tightly specified"? It depends on what we are releasing. If it's some addon to the 100'000 servers cluster which produces better statistic then estimate “will need no more then one additional server of regular capacity” may be perfectly good estimate but if it's something like “will need additional 3% of RAM” then it may be a big deal (3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look). In the end it's all about the money: if money lost (or “found” if we are measuring sales) are below certain threshold then, of course, resource consumption becomes a moot point, but when we are talking about services which have hundred millions of users then this threshold can be surprisingly low. Yes, there are times when the resource utilization really matters, but much of the time it doesn't matter that much, and other pressures (like time to market) matter much more. My experience is direct opposite. Yes, sometimes you only need rough estimate and don't care about 2x difference in memory or speed but you always care about 1000x difference. And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).
World-writable memory on Samsung Android phones Posted Dec 26, 2012 18:58 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
> And O(N²) instead of O(N) can produce 1000x difference pretty easily (while JIT-introduced memory consumption rarely produce more then 2x difference… latency is much bigger problem when JITs and GCs are involved).
I see a lot of stuff deployed without any consideration of these criteria.
> 3% of RAM will mean 3'000 new servers and these are expensive enough to warrant further look
This is what I was saying about not bothering about it until the cost becomes significant to care.
I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources
> Well, I guess we are living in totally different worlds. In my company "resources requirement" is one of the most important items in the release process.
don't make the assumption that every place (or even every large company) is like yours.
In an ideal world, these things would be considered, but in the real world it's frequently put out there on the basis that "it worked with a single user hitting it on the development machine" and only after mistakes take down production "too many times", does there start to be attention to resource usage.
World-writable memory on Samsung Android phones Posted Dec 27, 2012 20:50 UTC (Thu) by khim (subscriber, #9252) [Link] I see a lot of stuff deployed without any consideration of these criteria. Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come. You may be “first to market” but if your stuff stops working after 10'000th user (or after 100'000th user) then you are usually eaten alive by someone else who was second (or sometimes even third). Your only hope at this point is to sell this mess to someone with deep enough pockets and hope that redesign will survive. It rarely does. I've seen senior management say explicitly that they want to optimize for programming time over system resource usage, because they perceived hardware as 'cheap' compared to programming manpower, as the company grew, management started to care more about system resources. Well, that's why I'm talking about back-of-the envelope calculations. Quite often you only need to know resource usage very roughly. But it's one thing to estimate them imprecisely and explicitly refuse to spend time for too much fine-tuning and it's totally different thing to ignore resource requirements completely and not to even know if you need 10 times more servers with 10 times bigger userbase or 100 times more servers. I think the only programs where you can explicitly refuse to think about rough estimates are some parts of games: there are a lot of not-all-that-time-critical stuff where you can use Lua or Python and N does not grow so your requirements don't grow either. And gamedev is not something we are doing here. don't make the assumption that every place (or even every large company) is like yours. I'm not doing that! Not even close! I know there are a lot of companies and a lot of so-called “software engineers” who don't care about this stuff. That's their choice. We just don't want to see these aliens from parallel universe landing in our world, that's all. Take a look on the title of this article—it explains what goes on pretty succinctly (why would you are about time to reference memory if you don't know roughly how many times you'll need to do that in your program?). It does not mean that people are obsessed with all these numbers and complexities all the time—of course not. Often you just note something like “Ok, this is O(N) so will probably not be a bottleneck” or “fine, it's O(N³) memory, but we don't expect to ever see N > 10 thus it's Ok” in your head and happily go on with the implementation. Sometimes you need to actually stop and think if you want to fight for the smaller memory consumption or latency. But you usually do that at the design phase when changes are cheap and simple not when everything is deployed and the only way to fix something is try to add bazillion caches (and even they often don't help).
World-writable memory on Samsung Android phones Posted Jan 4, 2013 22:32 UTC (Fri) by nix (subscriber, #2304) [Link] Sure, if it's some kind of in-house program where N will not ever be more then, e.g. 1000, then it may work. If you are lucky. If we are talking about commercial software… it just does not fly. I've seen a lot of stuff deployed in such a fashion, but it all tanks when users really come.Sorry, that's rubbish. It may be true for mass-scale web software with millions of simultaneous users, but most software is not like that! I've written software in which I chose to use really crappy sorts in slow interpreted languages because I knew perfectly well that N for this application could never be above 16 without other invariants being invalidated that would necessitate rewriting the entire application. And this was for a major international bank throwing who knows how many billions of dollars a day around. I think that could be considered 'commercial software' (even if said bank *did* then proceed to shag itself and the economy of a major first-world nation, it was no fault of this software: that division was making money hand over fist and the software worked fine). (Of course, I had to pay attention to time and space complexity at times, and I frequently lamented the way my co-workers could not be bothered to do so. But that doesn't mean that you can always look at the complexity of an algorithm and conclude that you know something about the resource requirements of the system on which it sits, particularly if there are complex layers like modern server-class JVMs in the way. Note that particularly for time complexity all software has such layers in the way, because of the storage hierarchy; context switching and multicore architectures just make it worse, and virtual memory can make reasoning about space complexity into a rat's nest at times too. That's not to say you can't reason about it, but you certainly can't assume that an apaprent efficiency or inefficiency at one level translates into the same all the way up the stack.)
|
|||||||||||||