Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.gui > #603

Re: memory allocation for

From "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this>
Subject Re: memory allocation for
Message-ID <45a2e62a$0$8990$4c368faf@roadrunner.com> (permalink)
Newsgroups comp.lang.java.gui
References <45a2d24b$0$9574$4c368faf@roadrunner.com>
Date 2011-04-27 15:28 +0000
Organization TDS.net

Show all headers | View raw


  To: comp.lang.java.gui
Brandon McCombs wrote:
> Daniel Pitts wrote:
>> Brandon McCombs wrote:
>>> hello,
>>>
>>> My application makes multiple JNDI search calls to a directory server.
>>> The search method returns a NamingEnumeration of SearchResults and I run
>>> through a while loop that converts the enumeration to a Vector of
>>> SearchResults. At another time I process the Vector to add the
>>> SearchResults to a ListModel for viewing their properties.
>>>
>>> My application takes up a lot of memory after running that search
>>> operation a handful of times. It seems that the majority of the memory
>>> allocation comes from the hasMoreElements() method of the enumeration
>>> that I call within the while() mentioned above.  I don't see any way of
>>> not calling that method since I need it to grab the search results. The
>>> question I have is why would the JVM use so much space for that method
>>> and is there anything I can do to reclaim the memory?  JProfiler says
>>> that after a handful of search() executions there are over a million
>>> allocations of hasMoreElements() that take up 50 megs. Jprofiler shows
>>> garbage collections are occurring but since a method and not an Object
>>> is taking up the memory I don't know how to fix this problem.
>>>
>>> As a side note, if it was possible to properly cancel JNDI search
>>> methods (from the InitialLdapContext class) then I wouldn't have such a
>>> problem but once those searches start they can't be canceled from what I
>>> can gather, despite utilizing threads.
>>>
>>> thanks
>>> Brandon
>>
>> Method calls don't explicitly allocate memory.  I think you're
>> misinterpretting your profiler report.
>>
>> Also, why not use ArrayList instead of Vector?  Vector is outdated.
>>
>> Other then that, I don't have any advice to give you, sorry.
>>
> 
> In my opinion it is hard to interpret what I'm seeing any other way. In 
> case anyone is familiar with JProfiler, I'm on the Memory Views option, 
> on the Allocation Hot Spots tab within that view. The top hotspot is 
> "javax.naming.NamingEnumeration.hasMoreElements()" with allocated memory 
> of 47,997KB (92%) with 1,046,444 allocations. And that is using the 
> Aggregation Level of "methods".  I'll look into the ArrayList but I'd 
> like to fix the current problem before jumping to something else.
> 
> thanks

To add to this, I downloaded a Java app that does the same job as my app 
(just in a different way) and it runs into the same thing as my app 
based on what the profiler says. The issue just isn't as pronounced.

"results" is a NamingEnumeration
"node" is the tree node that was selected to retrieve children for

while (results != null && results.hasMoreElements()) {
	SearchResult si = (SearchResult)results.next();
	TreeNode2 t = new TreeNode2( si.getName(),
	si.getName() + ", " + searchbase);
	n = (BasicAttribute)si.getAttributes().get("numsubordinates");
	node.add(t);
}

The profiler says that the results.next() method is a Memory allocation 
hot spot that uses 15,370KB after 301,109 allocations.  My program 
actually has a  hotspot on the results.hasMoreElements() method as I 
mention above in a previous post.

If anyone has any suggestions as to what this means and if there is 
anything I can do about it let me know.

thanks
Brandon

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

Back to comp.lang.java.gui | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

memory allocation for a m "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
  Re: memory allocation for "Daniel Pitts" <daniel.pitts@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
    Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
      Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
  Re: memory allocation for "Nigel Wade" <nigel.wade@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
    Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000

csiph-web