|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
|
|
[Java Problem] Just for fun :-)Just for fun, what's wrong with this? :-)
package com.stc.test; import java.io.*; import java.util.logging.*; import javax.servlet.*; import javax.servlet.http.*; public class MyServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // Log at a custom level Level customLevel = new Level("OOPS", 555) {}; Logger.getLogger("test").log(customLevel, "doGet() called"); } } Clue: there's a mem leak :-) Disclaimer: This is not mine...this is from an article I saw sometime ago. If you want the answer/spoiler take a look at this ( * http://tinyurl.com/java-prob-spoiler* ) :-) Cheers, -- Franz Allan Valencia See | Java Software Engineer franz.see@... LinkedIn: http://www.linkedin.com/in/franzsee |
|
|
Re: [Java Problem] Just for fun :-)you create a class definition every time you invoke the doGet method?
On Wed, Oct 28, 2009 at 7:09 PM, Franz Allan Valencia See < franz.see@...> wrote: > > > Just for fun, what's wrong with this? :-) > > package com.stc.test; > > import java.io.*; > import java.util.logging.*; > import javax.servlet.*; > import javax.servlet.http.*; > > public class MyServlet extends HttpServlet { > > protected void doGet(HttpServletRequest request, HttpServletResponse response) > throws ServletException, IOException { > > // Log at a custom level > Level customLevel = new Level("OOPS", 555) {}; > > Logger.getLogger("test").log(customLevel, "doGet() called"); > > } > } > > > Clue: there's a mem leak :-) > > Disclaimer: This is not mine...this is from an article I saw sometime ago. > If you want the answer/spoiler take a look at this ( * > http://tinyurl.com/java-prob-spoiler* ) :-) > > Cheers, > -- > Franz Allan Valencia See | Java Software Engineer > franz.see@... > LinkedIn: http://www.linkedin.com/in/franzsee > > > |
|
|
Re: [Java Problem] Just for fun :-)Much worse :-)
The problem is in the implementation of the code(s) used here :-) On Thu, Oct 29, 2009 at 12:06 AM, Michael Mallete <mrmallete@...>wrote: > > > you create a class definition every time you invoke the doGet method? > > > On Wed, Oct 28, 2009 at 7:09 PM, Franz Allan Valencia See < > franz.see@...> wrote: > >> >> >> Just for fun, what's wrong with this? :-) >> >> package com.stc.test; >> >> import java.io.*; >> import java.util.logging.*; >> import javax.servlet.*; >> import javax.servlet.http.*; >> >> public class MyServlet extends HttpServlet { >> >> protected void doGet(HttpServletRequest request, HttpServletResponse response) >> throws ServletException, IOException { >> >> // Log at a custom level >> Level customLevel = new Level("OOPS", 555) {}; >> >> Logger.getLogger("test").log(customLevel, "doGet() called"); >> >> } >> } >> >> >> Clue: there's a mem leak :-) >> >> Disclaimer: This is not mine...this is from an article I saw sometime ago. >> If you want the answer/spoiler take a look at this ( * >> http://tinyurl.com/java-prob-spoiler* ) :-) >> >> Cheers, >> -- >> Franz Allan Valencia See | Java Software Engineer >> franz.see@... >> LinkedIn: http://www.linkedin.com/in/franzsee >> >> > > -- Franz Allan Valencia See | Java Software Engineer franz.see@... LinkedIn: http://www.linkedin.com/in/franzsee Twitter: http://www.twitter.com/franz_see |
|
|
Re: [Java Problem] Just for fun :-)On Thu, Oct 29, 2009 at 12:40 PM, Franz Allan Valencia See
<franz.see@...> wrote: > > Much worse :-) > > The problem is in the implementation of the code(s) used here :-) this is not "just for fun" - the problem and explanation is quite complicated. |
|
|
Re: [Java Problem] Just for fun :-)perm gen error will be thrown once you continuously redeploy this on app server.
________________________________ From: Franz Allan Valencia See <franz.see@...> To: pinoyjug@... Sent: Thu, October 29, 2009 12:40:17 PM Subject: Re: [pinoyjug] [Java Problem] Just for fun :-) Much worse :-) The problem is in the implementation of the code(s) used here :-) On Thu, Oct 29, 2009 at 12:06 AM, Michael Mallete <mrmallete@gmail. com> wrote: > > > > > > > > > > > > >> >you create a class definition every time you invoke the doGet method? > > > >On Wed, Oct 28, 2009 at 7:09 PM, Franz Allan Valencia See <franz.see@gmail. com> wrote: > >>> >> >> >> >> >> >> >> >> >> >> >> >>>> >>Just for fun, what's wrong with this? :-) >> >> >>package com.stc.test; >> >>import java.io.*; >>import java.util.logging. *; >>import javax.servlet. *; >>import javax.servlet. http.*; >> >>public class MyServlet extends HttpServlet { >>protected void doGet(HttpServletRequest request, HttpServletResponse response) >>throws ServletException, IOException { >>// Log at a custom level >> Level customLevel = new Level("OOPS", 555) {}; >> >> Logger.getLogger("test").log(customLevel, "doGet() called"); >> >> } >>} >>Clue: there's a mem leak :-) >> >>Disclaimer: This is not mine...this is from an article I saw sometime ago. If you want the answer/spoiler take a look at this ( http://tinyurl. com/java- prob-spoiler ) :-) >> >>Cheers, >>-- >>Franz Allan Valencia See | Java Software Engineer >>franz.see@gmail. com >>LinkedIn: http://www.linkedin.com/in/franzsee >> > -- Franz Allan Valencia See | Java Software Engineer franz.see@gmail. com LinkedIn: http://www.linkedin .com/in/franzsee Twitter: http://www.twitter. com/franz_ see |
|
|
Re: [Java Problem] Just for fun :-)Inferring from the code, It seems that whenever you create a new Level
object, it keeps a reference of the Level object created. *synchronized (Level.class) { known.add(this); }* where known is nothing but *private static* *java.util.ArrayList known = new java.util.ArrayList();* so known will grow for each invocation. Plus there are some nasty thread local hacks when you call *Logger.getLogger("test").log(customLevel, "doGet() called");* ** Every creation of LogRecord stores a thread local object containing the id. I am not really sure why they designed it that way. Are these the culprit fo the memory leak? Regards. Jerwin On Thu, Oct 29, 2009 at 3:44 PM, Rey Bumalay <core_reyj@...> wrote: > > > perm gen error will be thrown once you continuously redeploy this on app > server. > > ------------------------------ > *From:* Franz Allan Valencia See <franz.see@...> > *To:* pinoyjug@... > *Sent:* Thu, October 29, 2009 12:40:17 PM > *Subject:* Re: [pinoyjug] [Java Problem] Just for fun :-) > > > > Much worse :-) > > The problem is in the implementation of the code(s) used here :-) > > On Thu, Oct 29, 2009 at 12:06 AM, Michael Mallete <mrmallete@gmail. com<mrmallete@...> > > wrote: > >> >> >> you create a class definition every time you invoke the doGet method? >> >> >> On Wed, Oct 28, 2009 at 7:09 PM, Franz Allan Valencia See <franz.see@gmail. >> com <franz.see@...>> wrote: >> >>> >>> >>> Just for fun, what's wrong with this? :-) >>> >>> package com.stc.test; >>> >>> import java.io.*; >>> import java.util.logging. *; >>> import javax.servlet. *; >>> import javax.servlet. http.*; >>> >>> public class MyServlet extends HttpServlet { >>> >>> protected void doGet(HttpServletRequest request, HttpServletResponse response) >>> throws ServletException, IOException { >>> >>> // Log at a custom level >>> Level customLevel = new Level("OOPS", 555) {}; >>> >>> Logger.getLogger("test").log(customLevel, "doGet() called"); >>> >>> } >>> } >>> >>> >>> Clue: there's a mem leak :-) >>> >>> Disclaimer: This is not mine...this is from an article I saw sometime >>> ago. If you want the answer/spoiler take a look at this ( *http://tinyurl. >>> com/java- prob-spoiler <http://tinyurl.com/java-prob-spoiler>* ) :-) >>> >>> Cheers, >>> -- >>> Franz Allan Valencia See | Java Software Engineer >>> franz.see@gmail. com <franz.see@...> >>> LinkedIn: http://www.linkedin.com/in/franzsee >>> >>> >> > > > -- > Franz Allan Valencia See | Java Software Engineer > franz.see@gmail. com <franz.see@...> > LinkedIn: http://www.linkedin .com/in/franzsee<http://www.linkedin.com/in/franzsee> > Twitter: http://www.twitter. com/franz_ see<http://www.twitter.com/franz_see> > > > |
|
|
Re: [Java Problem] Just for fun :-)When I looked at the code, I know this is a trick scenario. So I didn't try to solve it anymore and just looked at the answer =p
And indeed, the scenario is very informative and very useful. Thanks for sharing this. --- On Thu, 10/29/09, Miguel Paraz <mparaz@...> wrote: From: Miguel Paraz <mparaz@...> Subject: Re: [pinoyjug] [Java Problem] Just for fun :-) To: pinoyjug@... Date: Thursday, October 29, 2009, 3:14 PM On Thu, Oct 29, 2009 at 12:40 PM, Franz Allan Valencia See <franz.see@gmail. com> wrote: > > Much worse :-) > > The problem is in the implementation of the code(s) used here :-) this is not "just for fun" - the problem and explanation is quite complicated. |
|
|
Re: [Java Problem] Just for fun :-)Since we are already plugging some puzzles, I would like to plug Dr Heinz
Kabutz's puzzle in his newsletter. The answer is in the newsletter after this one. http://www.javaspecialists.eu/archive/Issue173.html Cheers! On Fri, Oct 30, 2009 at 1:45 AM, vergil santos <gilsaints88@...>wrote: > > > When I looked at the code, I know this is a trick scenario. So I didn't try > to solve it anymore and just looked at the answer =p > > And indeed, the scenario is very informative and very useful. > > Thanks for sharing this. > > --- On *Thu, 10/29/09, Miguel Paraz <mparaz@...>* wrote: > > > From: Miguel Paraz <mparaz@...> > > Subject: Re: [pinoyjug] [Java Problem] Just for fun :-) > To: pinoyjug@... > Date: Thursday, October 29, 2009, 3:14 PM > > > > > On Thu, Oct 29, 2009 at 12:40 PM, Franz Allan Valencia See > <franz.see@gmail. com <http://mc/compose?to=franz.see%40gmail.com>> wrote: > > > > Much worse :-) > > > > The problem is in the implementation of the code(s) used here :-) > > this is not "just for fun" - the problem and explanation is quite > complicated. > > > > |
|
|
Re: [Java Problem] Just for fun :-)Nice puzzle, very interesting.
After running the code and modifying it to understand, I gather that: - if you put the byte[] data2 = new byte[dataSize]; to another method or inside the main and call it from the main just after the first method you don't get outOfMemory. - if you put the byte[] data2 = new byte[dataSize]; to another method and call it inside the first method you still get outOfMemory. (because the method is still in stack) - found out it's not about giving some time for the gc to garbage collect as the for loop may suggest since when I put a sleeping thread for quite a while just before the byte[] data2 = new byte[dataSize]; it just delays the outOfMemory. (or maybe i'm wrong) - found out that if you declare a variable and assign value to it, whether the variable is a primitive or an object, between the byte[] data = new byte[dataSize]; and the byte[] data2 - - new byte[dataSize]; then the outOfMemory is gone. - found out that if you just declare a variable, outOfMemory is still there. - found out that if you just instantiate an object (e.g. new String("blahg")), outOfMemory is still there - so what actually does it for the for (int i = 0; i < 1; i++) { System.out.println("Please be so kind and release memory"); } was the int = 0. Since if you put the initialization of int i somewhere else before calling the byte[] data = new byte[dataSize]; you still get outOfMemory. (assuming the int = 0 is outside the code block of byte[] data = new byte[dataSize]; so that gc will know data is not needed anymore) In summary: - when first method gets out of the stack (when it finishes), no outOfMemory. (because method is not in the stack anymore) - when declare a variable and assign value to it (variable should be outside code block of byte[] data = new byte[dataSize];), no outOfMemory. garbage collector only starts to work when the free memory is getting close the specified maximum. so with this move garbage collector starts to work because of the additional heap consumption. (not sure, will verify on free time). but I doubt if gc starts to work ONLY when the free memory is getting close the specified maximum though. since if I put in the first: byte[] data = new byte[Runtime.getRuntime().maxMemory() * 0.1]; and on the second: byte[] data2 = new byte[Runtime.getRuntime().maxMemory() * 0.9]; and put int i = 0; in between, still no outOfMemory. the data and int i = 0 shouldn't really get close to the specified max memory. Since: maxMemory = 66650112 0.1 = 6665011 hmm.. got to use profiler here to investigate further... lastly, found out I need to understand the indepth implementation/behavior of garbage collection in java more =p Thanks for the puzzle link. --- On Fri, 10/30/09, Jerwin Louise Uy <uy.jerwin@...> wrote: From: Jerwin Louise Uy <uy.jerwin@...> Subject: Re: [pinoyjug] [Java Problem] Just for fun :-) To: pinoyjug@... Date: Friday, October 30, 2009, 10:33 AM Since we are already plugging some puzzles, I would like to plug Dr Heinz Kabutz's puzzle in his newsletter. The answer is in the newsletter after this one. http://www.javaspec ialists.eu/ archive/Issue173 .html Cheers! On Fri, Oct 30, 2009 at 1:45 AM, vergil santos <gilsaints88@ yahoo.com> wrote: When I looked at the code, I know this is a trick scenario. So I didn't try to solve it anymore and just looked at the answer =p And indeed, the scenario is very informative and very useful. Thanks for sharing this. --- On Thu, 10/29/09, Miguel Paraz <mparaz@gmail. com> wrote: From: Miguel Paraz <mparaz@gmail. com> Subject: Re: [pinoyjug] [Java Problem] Just for fun :-) To: pinoyjug@yahoogroup s.com Date: Thursday, October 29, 2009, 3:14 PM On Thu, Oct 29, 2009 at 12:40 PM, Franz Allan Valencia See <franz.see@gmail. com> wrote: > > Much worse :-) > > The problem is in the implementation of the code(s) used here :-) this is not "just for fun" - the problem and explanation is quite complicated. |
| Free embeddable forum powered by Nabble | Forum Help |