This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Out Of Memory Error? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Out Of Memory Error?" Watch "Out Of Memory Error?" New topic
Author

Out Of Memory Error?

Abhi vijay
Ranch Hand

Joined: Sep 16, 2008
Posts: 509
During boxing operation, can Out Of Memory Error, be thrown???
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Technically, OutOfMemoryError can be thrown at any time, even when you sneeze at your computer screen. Would a boxing operation reliably cause an OutOfMemoryError? I don't see how, are you thinking of a particular scenario why this might be true?


All code in my posts, unless a source is explicitly mentioned, is my own.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2983
    
    9
Sure:

Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Hi Mike,

It's true that you are getting an OutOfMemoryError in your code. But, is it the boxing operation that is causing it? The following code gives the same error, with no boxing operation in sight:


The point I was trying to make is that anything that causes the JVM to run out of memory will cause the error. But is there anything specific in boxing that causes the error? I don't think so. The thing is that you can change any code to give the error, so saying that a boxing operation can cause the error seems redundant and misleading.

EDIT: However, I can see how using boxing would make the error happen faster, since I guess you can argue that an array of Integers takes more memory (when the elements are actually assigned to something other than the null reference) than an array of primitive ints due to the fact that you need to allocate an Integer object in the heap for each non-null element in the array.

Also, you can't still say that you will be able to cause an OutOfMemoryError reliably in any scenario, as the error taking place is dependent on the amount of memory available to the JVM. You could cause the error reliably under specific conditions (a given scenario) but if you can increase the memory available by an arbitrary number of bytes, then there is no reliable way that you can cause the error. This in in contrast to other type of errors which can be reliably caused using specific techniques (the simple case is the AssertionError.) I am not sure how the StackOverflowError is detected, and whether you could avoid one, even given a recursive call, by arbitrarily increasing a computer's memory to an infinite value. That would depend on how the error is detected (does the JVM use any heuristics to determine that the error has taken place?) I think it does, but I'm not sure.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2983
    
    9
Ruben wrote:It's true that you are getting an OutOfMemoryError in your code. But, is it the boxing operation that is causing it?

Yes. Check the stack trace - it points to the line where the boxing occurs. No other memory allocation occurs on that line, since the array has already been allocated.

Ruben wrote:The following code gives the same error, with no boxing operation in sight:

Well, what does that prove? The stack trace clearly tells us that this comes from the call to Arrays.toString(). Yes, it's possible for things other than boxing to cause OOME. I'm sure we could find many other examples of this if we cared - but that wasn't the question. I gave an example where the OOME is caused by boxing, not something else, because the question was whether boxing could cause an OOME.

Ruben wrote:Also, you can't still say that you will be able to cause an OutOfMemoryError reliably in any scenario, as the error taking place is dependent on the amount of memory available to the JVM.

The fact that it's dependent on the memory available doesn't make it unreliable - we can always explicitly specify this in the command line if we care using the -Xmx option. Quite reliably. In any scenario involving a JDK provided by Sun, which has the -Xmx option. "Reliably" is not the same as "in any conceivable scenario". It just means that if you want to reproduce the conditions that lead to the error, you can. Easily. And you can rely on it. If you want to create a different scenario where the error doesn't occur, you may be able to that too, but so what?

Let me put this another way. Let's say that I consider a person, Joe, to be reliable about getting to appointments on time. I may say "I can rely on Joe to meet me at 10:00 AM on Monday morning." When I make this statement, it's assumed that I'm actually trying to meet with Joe at 10 AM. And that I've told him about the appointment. Obviously if I actually told Joe to meet me at 11:00, he may be "late" for an appointment that was supposed to be at 10:00. But that's not Joe's fault.

Going back to the original problem: I can reliably create an OutOfMemoryError caused by boxing. If you don't want to do that, of if you want to create an OutOfMemoryError caused by something else, well, you can do something else. But I can still create an OutOfMemoryError caused by boxing. Reliably.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
You explained your points very clearly. I still maintain that there is nothing intrinsic to boxing that will create an OutOfMemoryError. The nature of the OutOfMemoryError is that it will be caused when you run out of memory, and that can happen for many different reasons. Can a boxing operation cause the error? Yes, but for that matter anything can. That was the point I was trying to make in my original response.

Again, when I say reliably I mean: Can you categorically say, by looking at the code, that a boxing operation will cause an OutOfMemoryError? The fact is that you can't, whereas you can reliably say that if you assert false; and you run the code with assertions enabled, that will reliably (as in always) throw an AssertionError. At this point we are getting into the semantics of "reliably." To me, reliably means "always." I can provide you a computer with 32 Mb of RAM that will reliably throw an OutOfMemoryError for a lot of different java programs (In that sense, the code will reliably throw the error for that specific computer.) I guess that I am looking at things from a more theoretical point of view, whereas you are taking into consideration the environment (and yes, I am aware that command-line options, including assertion enabling, to the java loader can be considered a factor in the environment.)

To recap: Can a boxing operation "cause" an OutOfMemoryError? Yes, it can. But, like I said in my original response, anything can. Also, the boxing operation is not causing the OutOfMemoryError, it is just "causing" it. The error is happening during a boxing operation (like you pointed out.) But is the operation actually causing the error? I am looking for a cause/effect relationship, and I fail to see one. You can argue that the boxing operation was the last drop of water that spilled the glass of the JVM's memory, but any other operation at that point would also have done that.

I think this is getting overly philosophical and of limited usefulness for the SCJP, but it is an interesting discussion nonetheless.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2983
    
    9
I don't agree with your suggestion that anything can cause an OOME. Things that allocate memory may cause OOME. Things that don't, can't. For example:

Assume x, y, and z are of primitive type, not Strings. Here x, y, and z must have all been allocated in memory before this line. Whether they're local, instance or class variables is immaterial. Wherever they were declared, that's the place that an OOME should have pointed to, if an OOME occurred. In the line above, all variables were already declared, and associated memory was allocated. Nothing on that line can cause an OOME.

Of course it's always possible that something done in another thread can cause an OOME. But in that case, the cause of the OOME was whatever action was performed in the other thread. A line like "z = x + y;" will never, ever, be the cause of an OOME.

If you disagree, here's a challenge for you: try to show us an example where the line "z = x + y;" might throw an OOME. Where x, y, and z are primitives, not Strings. And not wrapper classes either, since my original point in this thread was that boxing can cause OOME. Apparently we can't agree on what "reliably" means, but if you can describe to me a specific procedure that can recreate an OOME, even 1% of the time, I will consider my point to be disproved.

Ruben wrote:I guess that I am looking at things from a more theoretical point of view, whereas you are taking into consideration the environment


I think the bigger difference is between "can" and "will" - you seem to be mixing the two. The original question was whether boxing can cause an OOME. I've shown that it can. Maybe it doesn't always cause an OOME, in all possible environments. But it's very easy to create a specific environment where it can, and does. That is enough to confirm my original point.

You've suggested that an OOME can occur anywhere. I disagree, and have offered a specific counterexample. I assert that "z = x + y;" will never throw an OOME, if x, y, and z are all primitives. Can you provide any reliable counterexample? I'm prepared to be very flexible on the definition of "reliable", if it moves the discussion forward. Because I really don't think you can do it at all.

Wrapping up: I'm saying that boxing can cause OOME, because it can allocate memory. Many other things also allocate memory, and thus can cause OOME. However there are also many other operations that do not allocate memory, and thus cannot cause OOME. So, it's correct to say that boxing can cause OOME, but it's not correct to say that anything can cause OOME.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Obviously only things that allocate memory can cause an OOME. I thought that was implied by my statement, but I am glad that you are analyzing things in the most strict manner possible.

Notice however that an OOME will be thrown at any time that the JVM runs out of memory, and that could happen for reasons outside your own code. That's why I said that an OOME can happen at any time. Obviously, only parts of your code that allocate memory can be responsible for an OOME ultimately being thrown.

Also, I think I have never disagreed that a boxing operation can throw an OOME. I made that quite clear in my original reply to Abhi. It is at that point that I also said that I don't think that you can reliably cause an OOME with specific code, and that's when you provided your "counterexample." At that point, that's when I pointed out that that code won't reliably cause an OOME, because whether that code causes an OOME depends primarily on the amount of memory available. If there is a theoretical limit to the amount of memory allocated to a single JVM, then you might argue otherwise. You can perhaps provide that knowledge, since you seem to know quite a few things that I do not.

Going back to the main question, and since this is the SCJP forum, let's say that the exam provides your code with the following question:
Given the code above, what can be said about it?
A. It will reliably cause an OOME.
B. It will never cause an OOME.
C. It will throw a StackOverflowError.
D. It may cause an OOME under certain conditions.

Which one would you choose? I would choose D. The fact is that your code will not reliably cause an OOME to be thrown, because there is information missing in the question. That's my whole point, and why I think that providing your example without qualification, as a response to my request for an example that will produce an OOME reliably, might be a bit misleading.

It seems we are agreeing in the fundamentals, but that we can't reliably concur on what "reliably" means, however.
Reliably, to me, in the context of the exam, means "you can be certain it will always be that way, you can absolutely rely on it."
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Actually, it seems that there is a theoretical limit for the JVM:
The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems. ... If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications.

So, how much heap memory will that code use? I am quite interested now on whether you were unknowingly right all along. The exam will surely not have anything like this. Ahem...

Late breaking news:

On 64-bit VMs, you have 64 bits of addressability to work with resulting in a maximum Java heap size limited only by the amount of physical memory and swap space your system provides.

Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 2983
    
    9
Ruben wrote:Obviously only things that allocate memory can cause an OOME.

Glad to hear it. Your previous posts left me with quite a different impression. Between that and your, um, distinctive definition of "reliably" (where we can only look at Java code, not things like command-line arguments, for some reason), we seem to be spending a lot of time on nothing. Time for me to quit, I think. Life is too short.

If the original poster has any questions, I hope he will let us know.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Sorry to have wasted your time, sir. You provided a faulty example of code that "reliably" produces an OOME, and I simply pointed that out. There is no point in questioning whether I know the difference between "can" and "will" either, as despite the fact that English is not my native language, I believe that is quite a simple concept to grasp by most people. Also there is no point in issuing idle challenges for someone to prove something that is not true (and thus is unprovable.) The meaning of the word "reliably" is well defined however, and that is the exact reason why I pointed out that your code could not reliably produce an OOME. It can perhaps produce it in your machine, but then you are introducing an implicit factor into the equation, and that is not the way things should be
thought of. Nothing farther from my intent than offending you, but since it seems that that's exactly what I did, please accept my most sincere apologies.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Out Of Memory Error?
 
Similar Threads
OutOfMemory error ..
Out of Memory with high Free Memory
JVM memory allocation
ERROR DB597
Java is consuming to much memory.