Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.gui > #603
| 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 |
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 | Next — Previous in thread | Next in thread | Find similar
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