Memory management in Java

HI all,
I want to know what is memory management in JAVA means ?Is it related to memory management of java VM.?

Sorry for posting in wrong area. also sorry for cross posting . i close this discussion as i have posted a new topic. so dont reply plz.

Similar Messages

Memory Management in Java With Garbage Collector

i have so many doubts With Management in Java.
Please send me the Link
Thanqqqqqqq
Guru

Hi Guru,
The following link might be helpful to you:
http://java.sun.com/docs/hotspot/gc/
Regards,
Anuradha.B

Memory management strategy

I have a process that can benefit from lots of physical memory. I'm having trouble figuring out how to manage it.
Essentially, the process needs pages of memory to store data temporarily. When the systems hits some kind of memory limit, then it can flush all data to disk and start over. More memory significantly improves performance because flushes are less frequent.
The problem arises because I can't distinguish between physical and virtual memory, and I can't tell how much memory is available to me. When I grab too much memory, the whole process grinds to a halt because of swapping, or generates Out of Memory errors. Too little and performance is sub-optimal. Further complicating the situation is the fact that other threads are running in the same JVM consuming memory, and that we distribute this app into unknown environments with unknown amounts of memory.
So here are my thoughts so far:
Strategy 1:
Just allocate pages as needed until an OutOfMemoryError occurs. Trap it, flush, and continue. This works, but the app grinds to a halt once the system starts allocating virtual memory.
Strategy 2:
Allocate pages as needed until java.lang.getRuntime().freeMemory() drops below a threshhold value. This doesn't work because freeMemory() doesn't report the amount of free system memory, only the amount of free memory in the pool currently allocated from the operating system. On startup it could show as little as 2mb free on a 512mb machine.
Strategy 3:
Allocate pages up to a fixed amount, like 64mb. This fails when less than 64mb is free, and fails to take advantage of other memory that may be available. We could make this amount user-configurable, but most of our users aren't going to be capable of handling that.
Strategy 4:
Do something with soft or weak references. This has potential, but I can't figure out how to get notified when a reference is about to be garbage collected.
Anyone have better ideas?

To summarize: you would like to manage memory; real memory is faster than virtual memory; you can't tell how much real memory is available to you.
Let's take the middle statement: when you start using virtual memory, your application slows down? If that's the case, maybe you could have it time itself and when it starts slowing down, assume that's the cause. You'd have to have a standard bit of code that you could monitor for slowdowns. Of course that could be fooled if another task started eating the CPU, by for example doing a search-and-replace in a 100-MB document in memory. But likely you would be running this task on a dedicated system, or at least one without large competing tasks.
I think you're in uncharted territory here. I haven't seen any articles on this kind of memory management in Java. My suggestion would be to provide tuning parameters (such as maximum memory to use) and allow your users to adjust them based on actual conditions, instead of trying to have your application try to optimize itself. As you observe, your app doesn't have nearly enough information to do that.

Java Memory Management/Out of Memory

Hi Guys,
I have a few questions about java memory management
Because i keep encounter a lot of out of memory error which i think java does not handle Vector/ArrayList re initialisation automatically
Asumme i have 2 million record in database and , i will process every 80000 and store it in Vector
while(true)
list = new Vector();
list = GetResultFromDatabase() // Process Every 80000
if list.size() > 0 =======> My VEctor list contain 80000
//loop the 800000
//Process Some logic and data
list.clear();
list = null;
If u See , i need to call list.clear and list = Null every process so it wont cause me out of memory
Before i put that 2 lines , i always hit out of memory Exception.
Seems like garbage collector cannot claim memory if i dont declare
Is Memory Occupied by VEctor cannot be recoverable if we dont explitcitynya clear it and set it to NULL??
Because in term of logic wise it wont cause a problem if i just
do in this statement after it process like below
list = new Vector() which will reinstatiate the object.
Thanks.

Damm i should hacve read your post again
Look here:
while(true)
list = new Vector();What uer doing is craeting a new vector object everytime the while does an ityteration so when your while loop does 40000 loops there will be 40000 new objects in jou memory
i sugest moving the decleration outside the while loop:
list = new Vector();
while(true)
///rest of loop
} This could also be a problem
hope it help :-)
werns

Java Card Memory Managament: How do you free-up allocated memory?

I have a problem with java card memory management, that causes the applet to hang. I think the java card runs out of RAM when my applet runs for several iterations or process() calls. My program requires significant size of bytes for each APDU command to be sent. (around 100-250 bytes, for each apdu.sendBytes() call).
I use a temporary byte array buffer that will contain the APDU command to be sent, declared as:
private byte [] tmpBuff;Before each process() call, the tmBuff is initialized and contains a new byte array containing the APDU command to be sent. (array size around 100-250 bytes).
tmpBuff = new byte[] {0x00, ... } On the process() call, the tmpBuff is copied to APDU and sendBytes() function is called. The tmpBuff byte array is reinitialized after every process() call to contain the next command. After about 20 successful commands by the process() call, the applet seems to ran out of RAM and hangs.
I suspect, that when tmpBuff is reinitialized before each process() call, the Java Card garbage collector does now free-up the memory that was used for the previous tmpBuff byte array initialization.
Is there a way to reclaim the memory allocated for tmpBuff after it has been initialized?
Or maybe call the Java card garbage collector?

Cenon,
Generally speaking, the new keywork is a bad idea outside the install method or constructors as the JCRE is not guarenteed to have a garbage collector (and if it does, has to be called explicitly by JCSystem.requestObjectDeletion(); This however is slow.
A better option may be to use memory more efficiently than to rely on garbage collection. A way of doing this would be to have an instance variable that is initialised once and reused. This allows you to use either a transient or persistent array.
public class TestApplet extends Applet {
    private final static short BUFFER_SIZE = (short) 300;
    private final byte[] buffer;
    private TestApplet() {
        // only have one of the following not commented out
        /* persistent buffer */
        // buffer = new byte[BUFFER_SIZE];
        /* transient buffer (much faster) */
        buffer = JCSystem.makeTransientByteArray(BUFFER_SIZE, JCSystem.CLEAR_ON_DESELECT);
    public static void install(byte[] bArray, short bOffset, byte bLength) {
        // GP-compliant JavaCard applet registration
        new TestApplet().register(bArray, (short) (bOffset + 1), bArray[bOffset]);
    public void process(APDU apdu) {
        // Good practice: Return 9000 on SELECT
        if (selectingApplet()) {
            return;
        // do some work here with buffer
}In the above code you would be able to use the buffer to build the command and you will not have a memory leak.
Cheers,
Shane
Edited by: safarmer on Jul 8, 2008 12:25 PM

OSX inactive memory management problems

On my 2010 Macbook Air 11" running OSX 10.8 Mountain Lion, I have run into some major issues with memory management. This problem persists across both my Mac machines and multiple generations of OSX. I have a 2007 2.2 Ghz Core 2 Duo Macbook Pro Running Lion (upgraded from Tiger) with 3 gb 667Mhz DDR2 RAM and my 2010 Air 1.4Ghz Core 2 Duo (Upgraded from Snow Leopard to Mountain Lion) with 2gb 1067mhz DDR3 RAM. On both machines, for some time now, during normal usage; especially web browsing using Chrome and Safari (respectively); the inactive RAM on both machines will grow to consume around 30% of all RAM and force time consuming page outs to the mass storage drives on both machines. The Pro has a slower hard drive and the problem is the worst here, the air has a much faster SSD. I have found myself constantly having a window of Activity Monitor up on at least one of my desktops watching my RAM usage, using terminal to purge ram upwards of 10 times an hour to prevent costly page outs, especially on the Pro. I know Apple claims that inactive RAM is essentially free RAM that is temporarily storing recently used information for ease of access later and that it's supposed to be released as free memory when needed, but this obviously is not happening. Right now on my air my swap file is over 650Mb and I've seen it top 2Gb before. The air is exponentially better than the Pro due to the faster SSD, but I do notice substantial UI lag and a massive drop in fluidity as soon as my meager 2Gb is full and I start paging. The Pro is another story entirely, the entire system will essentially become unusable, having to wait several seconds for mouse clicks to even register. That's why I upgraded the stock 2Gb of RAM it comes with to 3Gb hoping that a 150% increase in RAM would help, but it just prolonged the inevitable. I still end up paging out just as bad across both systems if un checked. Even when I keep a close eye on memory usage and purge often, I still end up paging out because I'm not vigilant enough.
I have to limit my browsing to less than 5 tabs and keep my number of open programs less than 2 on both machines. My active and wired memory rarely seem to top 70%, meaning the rest gets taken by inactive, which isn't functioning as Apple claims. Even if my conclusions aobut what is happening under the hood are incorrect, something is going terribly wrong. I can't upgrade the RAM on my Air at all, and the RAM on my Pro is capped at 4Gb. I'm holding on upgrading because I don't think the excess hardware will solve this software memory problem. Whatever is happening is causing a serious drop in performance for me (yes I do know I have underpowered machines), but there has to be something I can do to speed performance. I've read about disabling the dynamic page file entirely, which just seems to crash the system when free memory is gone, and I've read about programs that claim to free memory. Those programs seem to work by taking a high priority in the process heigharchy of the OS and then proceeding to eat up large portions of RAM and releasing them as needed in an attempt to replicate the true intentions of inactive RAM, but I've heard of problems with this method as well. Does anyone have a viable solution? Monitoring my RAM usage myself and ensuring I don't end up paging out is costly, time consuming, annoying, and inefficient since I fail to catch the problem before I page if I get particularly busy. There is no other OS I've ever been acquainted with that has this problem, not any flavor of Linux, not even the dreaded windows. I seriously hope Apple can do something to manage this runaway memory problem. I'd like to be able to open more than 3 windows in Safari. I've had to purge 3 seperate times while writing this on my Air, and I now have 678 inactive memory, 741 inactive, 582 wired, and less than 14Mb free out of 2Gb with a growing swap at 680Mb. Each purge becomes less and less effective and the last one I did freed up only about 100Mb and it got eaten up again by inactive in less than 10 seconds. On my Air, the memory hog is Safari right now at 700Mb between the web content and flash player with only Facebook, youtube, and this Apple Supprt tab open. I have NO other applications running in the fore or background other than Activity Monitor and Terminal. On my Pro the memory hog is always kernel task, I use Chrome and Safari both. While the memory used by the browser does not usually take up the most substantial portion of the total used RAM out of any process, the more tabs I open, the more RAM I use. The browser is usually the second heaviest RAM hog to Kernel Task. So it seems that across the two machines there are two lsightly different manifestations of the same problem with the same results: massive performance drops and extremely annoying and costly page outs no matter the reason. I just want this problem to go away. I've used underpowered windows laptops that can open a dozen tabs in a heavier browser like IE or Firefox while using other programs like Word or Excel and more with no memory lag issues. There's no way in **** I could manage to open that many pages in a browser while using Pages and/or Numbers on either of my machines and expect reliable (swap free performance). This is just kind of sad in my opinion. Does anyone have a way to get my OSX machine running smooth so that I can remove the one thing that windows and Linux fan boys get the right to laugh at my Macs for?

Hi Zephryl,
I was actually able to get an initial response from Sun on this a few months ago. However, the Sun Swing team has not followed up on a resolution for this pervasive problem, even though they noticed the same problem when running a test applet I had created for them. Apparently, I.E. is not releasing memory from the heap.
Below is a quote from a Sun rep. on this in an e-mail sent to me on Dec 4, 2002:
"I suspected the leak is in the native code because the # of handles and GDI objects keep increasing but no obvious Java objects are left behind in the Java heap during page switch."
So, until Sun and/or Microsoft work out a solution to this, anyone who uses I.E. 6 and applets for their UI seems to be in a lot of trouble.
As a note, trying to invoke the Garbage Collector does not do anything, but generally a very small amount of memory will be released (like maybe 5-10% of the memory allocated for the applet).
Cheers!
Avi Gray
Global Computer Enterprises

Oracle 9i Automatic PGA Memory Management

Hello,
my team and me, we are facing difficulties to change the size of the PGA used by our server processes for HASH JOIN, SORT... operators,
here you can see the results of "select * from v$pgastat":
[pgastat dynamic view results|http://pastebin.com/m210314dc]
We have been increasing consecutively our pga_aggregate_target parameter from 1.7 Gb initially to 4Gb then at the end 6Gb, the value of "Global memory bound" and " aggregate pga auto target" on the link above are still equal to 0.
I have been reading threads on the forum and documentation see below, I understand how the global memory manager (CKPT) computest the sql memory target and then the global memory bound, as far as I understand I can only "play" on the pga_aggregate_target value in order to increase the size of our PGAs (I exclude to play with hidden parameters).
- Joze Senegacnik: Advanced Management of working areas in Oracle 9i/10g : http://tonguc.yilmaz.googlepages.com/JozeSenegacnik-PGAMemoryManagementvO.zip
- Dageville Benoit and Zait Mohamed: SQL memory management in oracle 9i
Here different information that could be usefull:
OS: solaris 10 (db running in a non global zone)
Arch: 64-bit sparcv9 kernel modules
Physical memory: 32 Gb (being shared between all non global zones)
Oracle version: 9.2.0.5 32bits
Values of init parameters and hidden parameters that could be relevant:
[init parameters|http://pastebin.com/m40340cf4]
[hidden parameters|http://pastebin.com/m50d74c53]
Maybe useful queries:
over work areas views, I use the following script:
[wa_analysis.sql|http://pastebin.com/d606ebd9b]
and the result of it:
[result of script wa_analysis.sql|http://pastebin.com/m5f49a2e5]

Joze Senegacnik wrote:
- either your sessions are using a lot of memory for storing variables like pl/sql arrays which is subtracted from automatic management: PGA_AGGREGATE_TARGET - (aggregated persistent area + a part of the run time area of all server processes)
- you are hitting a bug
- or maybe something elseI am really happy you come to this conclusion too, they are the same we made with my team and we have submitting to Oracle support via metalink SR 3-1216060641, we were asking if we hit the following bug (in note 1) or we leak about pl/sql or java... or else indeed,
note 1: PGA_AGGREGATE_TARGET Assigned Memory Is Left Unconsumed When Set High [ID 844542.1]
Joze Senegacnik wrote:
I would like to know:
1.) what were the values for global memory bound and autotarget immediately (or in short time) after the database restart or when you have increased them Just after the restart of the database and just after the change of P_A_T, we query v$pgastat immediately after and the value of global memory bound and auto target were equal to 0 byte,
2.) If you are able to change value of PGA_AGGREGATE_TARGET (P_A_T) to 10GB what happens with global memory bound and auto traget. They should be positive at least for a short time. As this is a dynamic parameter you can change it for a short time, run queries and set it back.We plan to do this tonight, we have an "heavy" ITIL change management procedures that allow us to make changes approved by change manager and only during night maintenance window on production system, I come back to you tomorrow. But we have been increasing from 1,7Gb to 4Gb to 6Gb, each time I have been querying v$sgastat in the next 2 mins and global memory bound and auto target were equal to 0 byte.
3.) Have you checked on the OS level how much memory are using server processes - do these numbers come along with what Oracle says. Not during problematic activities, meaning active work areas performing HASH-JOIN, SORT... operators,
unfortunately it is a production system, even if he performs poorly, we are not allowed to try or retry the poor queries, but if it comes again I'll do it,
during low activities, here the results paste with the scripts I used:
[pga processes info in oracle|http://pastebin.com/f2e540062]
I spooled the result rows of this previous script in /var/tmp/pga_processes.log then I loop over all processes pid and display pmap output anon info like this:
h5. cat /var/tmp/pga_processes.log | awk -F' ' '{print $5}' | xargs -n 1 -i pmap -x {}| grep -v 'Addres' |egrep 'Kb' 2>&1 > /var/tmp/pga_processes_os.log
then I merge line by line the two files with unix paste command, here the results:
[os and oracle pga informations|http://pastebin.com/f4135c8a6]
4.) How many server processes are running on you system in average/max and are you using just dedicated processes or also shared?in average 250, we are only using dedicated processes,
5.) At time of low activity is the global memory bound still 0 or becomes > 0. I have been querying every 15 min during more than 24 hours low activities, it still stay to 0,
5.) Are you experiencing paging/swapping on OS level?No, here orca figures for details:
[free memory|http://img509.imageshack.us/img509/5897/ohuron1asd2gauge1024xfr.png]
swap
[pagein pageout|http://img121.imageshack.us/img121/6946/ohuron1asd2gaugepginper.png]
[memory usage|http://img19.imageshack.us/img19/2213/ohuron1asd2gaugeppkerne.png]
6.) Please post the result of: select * from X$QESMMSGA ;during low activities, [results X$QESMMSGA|http://pastebin.com/f61df7093]
While you will be answering to my questions I'll try to figure out what we can do to properly diagnose the problem. As you are on 9i it is a little bit harder.I am really kind of your help, as we say in my country, "if you need tow arms one day to carry something, call me."
--Jeremy Baumont

There is insufficient memory for the Java Runtime Environment to continue,JVM crash with high virtual memory on windows

Hello,
Virtual Memory of tomcat(version is 6.0.35) is very high and jvm crash even though we decrease java heap size from 1024M to 500M.
Below is whole log. Please give me some suggestion. Thanks.
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 666390 bytes for jbyte in C:\BUILD_AREA\jdk6_45\hotspot\src\share\vm\prims\jni.cpp
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
# Out of Memory Error (memory/allocation.inline.hpp:44), pid=9084, tid=8100
# JRE version: 6.0_45-b06
# Java VM: Java HotSpot(TM) Client VM (20.45-b01 mixed mode, sharing windows-x86 )
--------------- T H R E A D ---------------
Current thread (0x045a5400): JavaThread "Thread-69" [_thread_in_vm, id=8100, stack(0x090e0000,0x09120000)]
Stack: [0x090e0000,0x09120000], sp=0x0911f56c, free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
[error occurred during error reporting (printing native stack), id 0xe0000000]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J com.neva.ExternalObject.toExternalHeap2([BI)I
J com.neva.ExternalObject.<init>([BII)V
J com.neva.Coroutine.addArgUnicodeString(Ljava/lang/String;)V
j com.neva.COMBSTR.<init>(Ljava/lang/String;)V+29
j com.neva.COMVariant.<init>(Ljava/lang/String;)V+19
J com.cpcus.jaru.protocol.impl.combridge.wizardgen.IJaruProtocol1.registerInterest(Ljava/lang/String;Ljava/lang/String;[ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;)V
j sun.reflect.GeneratedMethodAccessor844.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+170
J sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;
J com.cpcus.jaru.util.concurent.ComMethodExecutor$ExecutableMethod.call()Ljava/lang/Object;
J EDU.oswego.cs.dl.util.concurrent.FutureResult$1.run()V
J com.cpcus.jaru.util.concurent.QueuedExecutor$MyRunLoop.run()V
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x044fe000 JavaThread "Thread-1099" daemon [_thread_blocked, id=8048, stack(0x4c4d0000,0x4c510000)]
0x044f8c00 JavaThread "Thread-1098" daemon [_thread_blocked, id=1744, stack(0x46e50000,0x46e90000)]
0x044cd000 JavaThread "Thread-1095" daemon [_thread_in_native, id=6176, stack(0x00bb0000,0x00c20000)]
0x04c7f800 JavaThread "Thread-1094" daemon [_thread_blocked, id=7352, stack(0x0d340000,0x0d380000)]
0x04c7dc00 JavaThread "Thread-1093" daemon [_thread_in_native, id=1364, stack(0x0bbd0000,0x0bc10000)]
0x044fcc00 JavaThread "http-80-72" daemon [_thread_blocked, id=1580, stack(0x42110000,0x42150000)]
0x044fc000 JavaThread "http-80-71" daemon [_thread_blocked, id=2996, stack(0x0cd10000,0x0cd50000)]
0x044fb800 JavaThread "http-80-70" daemon [_thread_in_native, id=5004, stack(0x0cc90000,0x0ccd0000)]
0x044fd800 JavaThread "http-80-69" daemon [_thread_blocked, id=8776, stack(0x0f950000,0x0f990000)]
0x044fb400 JavaThread "http-80-68" daemon [_thread_blocked, id=8440, stack(0x0f8d0000,0x0f910000)]
0x044f8000 JavaThread "http-80-67" daemon [_thread_in_native, id=5516, stack(0x0f850000,0x0f890000)]
0x044fd400 JavaThread "http-80-66" daemon [_thread_blocked, id=876, stack(0x0f6d0000,0x0f710000)]
0x044fac00 JavaThread "http-80-65" daemon [_thread_in_native, id=8332, stack(0x0f690000,0x0f6d0000)]
0x044fa800 JavaThread "http-80-64" daemon [_thread_in_native, id=6848, stack(0x0f610000,0x0f650000)]
0x044fc800 JavaThread "http-80-63" daemon [_thread_blocked, id=5996, stack(0x0f590000,0x0f5d0000)]
0x044fa000 JavaThread "http-80-62" daemon [_thread_blocked, id=4876, stack(0x0cf90000,0x0cfd0000)]
0x044f9c00 JavaThread "http-80-61" daemon [_thread_blocked, id=5532, stack(0x0f550000,0x0f590000)]
0x044f9400 JavaThread "http-80-60" daemon [_thread_in_native, id=1764, stack(0x0f4d0000,0x0f510000)]
0x044f8800 JavaThread "http-80-59" daemon [_thread_blocked, id=6108, stack(0x0f450000,0x0f490000)]
0x044f7400 JavaThread "http-80-58" daemon [_thread_in_native, id=6892, stack(0x0d400000,0x0d440000)]
0x04ab3000 JavaThread "http-80-57" daemon [_thread_in_native, id=6932, stack(0x0d2c0000,0x0d300000)]
0x0436b400 JavaThread "http-80-56" daemon [_thread_blocked, id=644, stack(0x0d240000,0x0d280000)]
0x0436a000 JavaThread "http-80-55" daemon [_thread_in_native, id=6772, stack(0x0d1c0000,0x0d200000)]
0x04c80c00 JavaThread "http-80-54" daemon [_thread_in_native, id=2732, stack(0x0d140000,0x0d180000)]
0x04c80800 JavaThread "http-80-53" daemon [_thread_in_native, id=4172, stack(0x0d0c0000,0x0d100000)]
0x04c80000 JavaThread "http-80-52" daemon [_thread_blocked, id=2512, stack(0x0d040000,0x0d080000)]
0x044cdc00 JavaThread "http-80-51" daemon [_thread_in_native, id=6260, stack(0x0ced0000,0x0cf10000)]
0x04c7d400 JavaThread "http-80-50" daemon [_thread_blocked, id=4336, stack(0x0ce90000,0x0ced0000)]
0x0436d400 JavaThread "http-80-49" daemon [_thread_blocked, id=2484, stack(0x0ce10000,0x0ce50000)]
0x0436dc00 JavaThread "http-80-48" daemon [_thread_in_native, id=8396, stack(0x0c840000,0x0c880000)]
0x0436cc00 JavaThread "http-80-47" daemon [_thread_blocked, id=8300, stack(0x0c9c0000,0x0ca00000)]
0x0436c800 JavaThread "H2 Log Writer FRAMEDB" daemon [_thread_blocked, id=7556, stack(0x0cc10000,0x0cc50000)]
0x0436bc00 JavaThread "H2 File Lock Watchdog C:\Program Files (x86)\Tomcat\webapps\emerson\vault\dbframe\h2\framedb.lock.db" daemon [_thread_blocked, id=7236, stack(0x0c940000,0x0c980000)]
0x0436c000 JavaThread "http-80-46" daemon [_thread_in_native, id=5128, stack(0x0c8c0000,0x0c900000)]
0x0436b000 JavaThread "http-80-45" daemon [_thread_blocked, id=7860, stack(0x0c0c0000,0x0c100000)]
0x0436a800 JavaThread "http-80-44" daemon [_thread_in_native, id=8244, stack(0x0bfc0000,0x0c000000)]
0x04ab2800 JavaThread "http-80-43" daemon [_thread_blocked, id=6656, stack(0x0c7c0000,0x0c800000)]
0x04ab2000 JavaThread "http-80-42" daemon [_thread_blocked, id=8412, stack(0x0c740000,0x0c780000)]
0x04ab1c00 JavaThread "http-80-41" daemon [_thread_in_native, id=6300, stack(0x0c6c0000,0x0c700000)]
0x04ab1400 JavaThread "http-80-40" daemon [_thread_blocked, id=4312, stack(0x0c640000,0x0c680000)]
0x04ab1000 JavaThread "http-80-39" daemon [_thread_blocked, id=5480, stack(0x0c5c0000,0x0c600000)]
0x04ab0800 JavaThread "http-80-38" daemon [_thread_blocked, id=8648, stack(0x0c540000,0x0c580000)]
0x04ab0400 JavaThread "http-80-37" daemon [_thread_blocked, id=8008, stack(0x0c4c0000,0x0c500000)]
0x04aafc00 JavaThread "http-80-36" daemon [_thread_in_native, id=8496, stack(0x0c340000,0x0c380000)]
0x04aaf400 JavaThread "http-80-35" daemon [_thread_blocked, id=6616, stack(0x0c2c0000,0x0c300000)]
0x044cf000 JavaThread "http-80-34" daemon [_thread_blocked, id=3852, stack(0x0c240000,0x0c280000)]
0x044ce800 JavaThread "http-80-33" daemon [_thread_blocked, id=8828, stack(0x0c1c0000,0x0c200000)]
0x044ce400 JavaThread "http-80-32" daemon [_thread_blocked, id=4076, stack(0x0c140000,0x0c180000)]
0x044cc400 JavaThread "http-80-31" daemon [_thread_blocked, id=888, stack(0x0be90000,0x0bed0000)]
0x044cbc00 JavaThread "http-80-30" daemon [_thread_blocked, id=8524, stack(0x0be10000,0x0be50000)]
0x044cd800 JavaThread "AWT-Windows" daemon [_thread_in_native, id=6500, stack(0x0c040000,0x0c080000)]
0x044ccc00 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=8888, stack(0x0bf40000,0x0bf80000)]
0x045a5800 JavaThread "MonitorThreadCountsAndMemory" daemon [_thread_blocked, id=760, stack(0x09160000,0x091a0000)]
0x04742400 JavaThread "Thread-116" daemon [_thread_blocked, id=8208, stack(0x0bdd0000,0x0be10000)]
0x04742c00 JavaThread "Thread-115" daemon [_thread_blocked, id=6160, stack(0x0bd30000,0x0bd70000)]
0x04742000 JavaThread "TP-Monitor" daemon [_thread_blocked, id=4676, stack(0x0b730000,0x0b770000)]
0x04741800 JavaThread "TP-Processor4" daemon [_thread_in_native, id=7904, stack(0x0b6b0000,0x0b6f0000)]
0x04741000 JavaThread "TP-Processor3" daemon [_thread_blocked, id=3892, stack(0x0b630000,0x0b670000)]
0x04740c00 JavaThread "TP-Processor2" daemon [_thread_blocked, id=8200, stack(0x0b5b0000,0x0b5f0000)]
0x04740400 JavaThread "TP-Processor1" daemon [_thread_blocked, id=8240, stack(0x0b530000,0x0b570000)]
0x04740000 JavaThread "http-80-29" daemon [_thread_blocked, id=8952, stack(0x0b4b0000,0x0b4f0000)]
0x0473f800 JavaThread "http-80-28" daemon [_thread_in_native, id=5804, stack(0x0b430000,0x0b470000)]
0x0473f400 JavaThread "http-80-27" daemon [_thread_blocked, id=8768, stack(0x0b3b0000,0x0b3f0000)]
0x0473ec00 JavaThread "http-80-26" daemon [_thread_in_native, id=8428, stack(0x0b330000,0x0b370000)]
0x0473e400 JavaThread "http-80-25" daemon [_thread_blocked, id=6328, stack(0x0b2b0000,0x0b2f0000)]
0x0473e000 JavaThread "http-80-24" daemon [_thread_in_native, id=7856, stack(0x0b230000,0x0b270000)]
0x0473d800 JavaThread "http-80-23" daemon [_thread_in_native, id=8212, stack(0x0b1b0000,0x0b1f0000)]
0x0473d400 JavaThread "http-80-22" daemon [_thread_blocked, id=7572, stack(0x0b130000,0x0b170000)]
0x0473cc00 JavaThread "http-80-21" daemon [_thread_in_native, id=4112, stack(0x0b0b0000,0x0b0f0000)]
0x0473c800 JavaThread "http-80-20" daemon [_thread_in_native, id=1788, stack(0x0b030000,0x0b070000)]
0x0473c000 JavaThread "http-80-19" daemon [_thread_blocked, id=6804, stack(0x0afb0000,0x0aff0000)]
0x0473b800 JavaThread "http-80-18" daemon [_thread_in_native, id=1600, stack(0x0af30000,0x0af70000)]
0x0473b400 JavaThread "http-80-17" daemon [_thread_in_native, id=5728, stack(0x0aeb0000,0x0aef0000)]
0x04acc400 JavaThread "http-80-16" daemon [_thread_blocked, id=8728, stack(0x0ae30000,0x0ae70000)]
0x04acbc00 JavaThread "http-80-15" daemon [_thread_blocked, id=5868, stack(0x0adb0000,0x0adf0000)]
0x04acb800 JavaThread "http-80-14" daemon [_thread_blocked, id=6976, stack(0x0ad30000,0x0ad70000)]
0x04acb000 JavaThread "http-80-13" daemon [_thread_blocked, id=6168, stack(0x0acb0000,0x0acf0000)]
0x04acac00 JavaThread "http-80-12" daemon [_thread_blocked, id=2592, stack(0x0ac30000,0x0ac70000)]
0x04aca400 JavaThread "http-80-11" daemon [_thread_in_native, id=7936, stack(0x0abb0000,0x0abf0000)]
0x04aca000 JavaThread "http-80-10" daemon [_thread_in_native, id=7532, stack(0x0ab30000,0x0ab70000)]
0x04ac9800 JavaThread "http-80-9" daemon [_thread_blocked, id=7704, stack(0x0aab0000,0x0aaf0000)]
0x04ac9400 JavaThread "http-80-8" daemon [_thread_in_native, id=8852, stack(0x0aa30000,0x0aa70000)]
0x04ac8c00 JavaThread "http-80-7" daemon [_thread_blocked, id=5052, stack(0x0a9b0000,0x0a9f0000)]
0x04ac8400 JavaThread "http-80-6" daemon [_thread_blocked, id=5932, stack(0x0a930000,0x0a970000)]
0x04ac8000 JavaThread "http-80-5" daemon [_thread_blocked, id=8992, stack(0x0a8b0000,0x0a8f0000)]
0x04ac7800 JavaThread "http-80-4" daemon [_thread_in_native, id=6396, stack(0x0a830000,0x0a870000)]
0x04ac7400 JavaThread "http-80-3" daemon [_thread_in_native, id=8764, stack(0x0a7b0000,0x0a7f0000)]
0x04ac6c00 JavaThread "http-80-2" daemon [_thread_in_native, id=2608, stack(0x0a730000,0x0a770000)]
0x04ac6800 JavaThread "http-80-1" daemon [_thread_in_native, id=5736, stack(0x0a6b0000,0x0a6f0000)]
0x04ac6000 JavaThread "http-80-Acceptor-0" daemon [_thread_in_native, id=5912, stack(0x0a630000,0x0a670000)]
0x04ac5800 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=6984, stack(0x0a5b0000,0x0a5f0000)]
0x04ac5400 JavaThread "Thread-79" [_thread_in_native, id=1512, stack(0x0a530000,0x0a570000)]
0x04ac4c00 JavaThread "QuartzScheduler_JaruQuartzSchedulerUser-3_MisfireHandler" [_thread_blocked, id=7460, stack(0x0a4b0000,0x0a4f0000)]
0x0479f800 JavaThread "QuartzScheduler_JaruQuartzSchedulerSystem-2_MisfireHandler" [_thread_blocked, id=7164, stack(0x0a430000,0x0a470000)]
0x0479f400 JavaThread "JaruQuartzSchedulerUser_QuartzSchedulerThread" [_thread_blocked, id=8972, stack(0x0a3b0000,0x0a3f0000)]
0x0479ec00 JavaThread "JaruQuartzSchedulerUser_Worker-4" [_thread_blocked, id=4032, stack(0x0a330000,0x0a370000)]
0x0479e400 JavaThread "JaruQuartzSchedulerUser_Worker-3" [_thread_blocked, id=7432, stack(0x0a2b0000,0x0a2f0000)]
0x0479e000 JavaThread "JaruQuartzSchedulerUser_Worker-2" [_thread_blocked, id=7932, stack(0x0a230000,0x0a270000)]
0x0479d800 JavaThread "JaruQuartzSchedulerUser_Worker-1" [_thread_blocked, id=4896, stack(0x0a1b0000,0x0a1f0000)]
0x0479d400 JavaThread "JaruQuartzSchedulerSystem_QuartzSchedulerThread" [_thread_blocked, id=7380, stack(0x0a130000,0x0a170000)]
0x0479cc00 JavaThread "JaruQuartzSchedulerSystem_Worker-9" [_thread_blocked, id=5416, stack(0x0a0b0000,0x0a0f0000)]
0x0479c800 JavaThread "JaruQuartzSchedulerSystem_Worker-8" [_thread_blocked, id=5432, stack(0x0a030000,0x0a070000)]
0x0479c000 JavaThread "JaruQuartzSchedulerSystem_Worker-7" [_thread_blocked, id=7812, stack(0x09fb0000,0x09ff0000)]
0x0479b800 JavaThread "JaruQuartzSchedulerSystem_Worker-6" [_thread_blocked, id=8296, stack(0x09f30000,0x09f70000)]
0x0479b400 JavaThread "JaruQuartzSchedulerSystem_Worker-5" [_thread_blocked, id=5216, stack(0x09eb0000,0x09ef0000)]
0x0479ac00 JavaThread "JaruQuartzSchedulerSystem_Worker-4" [_thread_blocked, id=8616, stack(0x09e30000,0x09e70000)]
0x0479a800 JavaThread "JaruQuartzSchedulerSystem_Worker-3" [_thread_blocked, id=9108, stack(0x09db0000,0x09df0000)]
0x0479a000 JavaThread "JaruQuartzSchedulerSystem_Worker-2" [_thread_blocked, id=7928, stack(0x09d30000,0x09d70000)]
0x04799c00 JavaThread "JaruQuartzSchedulerSystem_Worker-1" [_thread_blocked, id=5344, stack(0x09cb0000,0x09cf0000)]
0x04799400 JavaThread "DefaultQuartzScheduler_QuartzSchedulerThread" [_thread_blocked, id=5288, stack(0x09c30000,0x09c70000)]
0x04798c00 JavaThread "DefaultQuartzScheduler_Worker-10" [_thread_blocked, id=6200, stack(0x09bb0000,0x09bf0000)]
0x04798800 JavaThread "DefaultQuartzScheduler_Worker-9" [_thread_blocked, id=9068, stack(0x09b30000,0x09b70000)]
0x04798000 JavaThread "DefaultQuartzScheduler_Worker-8" [_thread_blocked, id=8576, stack(0x09ab0000,0x09af0000)]
0x045abc00 JavaThread "DefaultQuartzScheduler_Worker-7" [_thread_blocked, id=2504, stack(0x09a30000,0x09a70000)]
0x045ab800 JavaThread "DefaultQuartzScheduler_Worker-6" [_thread_blocked, id=7820, stack(0x099b0000,0x099f0000)]
0x045ab000 JavaThread "DefaultQuartzScheduler_Worker-5" [_thread_blocked, id=4604, stack(0x09930000,0x09970000)]
0x045aa800 JavaThread "DefaultQuartzScheduler_Worker-4" [_thread_blocked, id=3076, stack(0x098b0000,0x098f0000)]
0x045aa400 JavaThread "DefaultQuartzScheduler_Worker-3" [_thread_blocked, id=8392, stack(0x09830000,0x09870000)]
0x045a9c00 JavaThread "DefaultQuartzScheduler_Worker-2" [_thread_blocked, id=476, stack(0x097b0000,0x097f0000)]
0x045a9800 JavaThread "DefaultQuartzScheduler_Worker-1" [_thread_blocked, id=9024, stack(0x09730000,0x09770000)]
0x045a9000 JavaThread "JaruQuartzScheduler_QuartzSchedulerThread" [_thread_blocked, id=7576, stack(0x00820000,0x00860000)]
0x045a8c00 JavaThread "Thread-75" [_thread_blocked, id=2132, stack(0x096b0000,0x096f0000)]
0x045a8400 JavaThread "TacAlarmMon" [_thread_blocked, id=7244, stack(0x09630000,0x09670000)]
0x045a7c00 JavaThread "Thread-74" [_thread_blocked, id=2728, stack(0x095b0000,0x095f0000)]
0x045a7800 JavaThread "MonConnMgr3002" [_thread_in_native, id=7444, stack(0x09530000,0x09570000)]
0x045a7000 JavaThread "Timer-1" [_thread_blocked, id=8272, stack(0x094b0000,0x094f0000)]
0x045a6c00 JavaThread "Thread-72" [_thread_blocked, id=6512, stack(0x09430000,0x09470000)]
0x045a6400 JavaThread "MonConnMgr3001" [_thread_in_native, id=5284, stack(0x093b0000,0x093f0000)]
0x045a6000 JavaThread "Timer-0" [_thread_blocked, id=2932, stack(0x09330000,0x09370000)]
=>0x045a5400 JavaThread "Thread-69" [_thread_in_native_trans, id=8100, stack(0x090e0000,0x09120000)]
0x045a4c00 JavaThread "Thread-68" [_thread_blocked, id=7160, stack(0x09060000,0x090a0000)]
0x045a4400 JavaThread "Thread-67" [_thread_blocked, id=2212, stack(0x08fe0000,0x09020000)]
0x04875400 JavaThread "Thread-66" [_thread_blocked, id=7180, stack(0x08f60000,0x08fa0000)]
0x04875000 JavaThread "Thread-65" [_thread_blocked, id=2672, stack(0x08ee0000,0x08f20000)]
0x04874800 JavaThread "Thread-64" [_thread_blocked, id=8456, stack(0x08e60000,0x08ea0000)]
0x04874000 JavaThread "Thread-63" [_thread_blocked, id=7708, stack(0x08de0000,0x08e20000)]
0x04873c00 JavaThread "Thread-62" [_thread_blocked, id=9204, stack(0x08d60000,0x08da0000)]
0x04873400 JavaThread "Thread-61" [_thread_blocked, id=1496, stack(0x08ce0000,0x08d20000)]
0x04873000 JavaThread "Thread-60" [_thread_blocked, id=3480, stack(0x08c60000,0x08ca0000)]
0x04872800 JavaThread "Thread-59" [_thread_blocked, id=7740, stack(0x08be0000,0x08c20000)]
0x04872400 JavaThread "Thread-58" [_thread_blocked, id=3496, stack(0x08b60000,0x08ba0000)]
0x04871c00 JavaThread "Thread-57" [_thread_blocked, id=4892, stack(0x08ae0000,0x08b20000)]
0x04871400 JavaThread "Thread-56" [_thread_blocked, id=5640, stack(0x08a60000,0x08aa0000)]
0x04871000 JavaThread "Thread-55" [_thread_blocked, id=8120, stack(0x089e0000,0x08a20000)]
0x04870800 JavaThread "Thread-54" [_thread_blocked, id=5388, stack(0x08960000,0x089a0000)]
0x04870400 JavaThread "Thread-53" [_thread_blocked, id=7072, stack(0x088e0000,0x08920000)]
0x0486fc00 JavaThread "Thread-52" [_thread_blocked, id=7184, stack(0x08860000,0x088a0000)]
0x0486f800 JavaThread "Thread-51" [_thread_blocked, id=8760, stack(0x087e0000,0x08820000)]
0x0486f000 JavaThread "Thread-50" [_thread_blocked, id=2380, stack(0x08760000,0x087a0000)]
0x0486e800 JavaThread "Thread-49" [_thread_blocked, id=3616, stack(0x086e0000,0x08720000)]
0x0486e400 JavaThread "Thread-48" [_thread_blocked, id=5056, stack(0x08660000,0x086a0000)]
0x0486dc00 JavaThread "Thread-47" [_thread_blocked, id=5468, stack(0x085e0000,0x08620000)]
0x0485a000 JavaThread "Thread-46" [_thread_blocked, id=8556, stack(0x08560000,0x085a0000)]
0x04859c00 JavaThread "Thread-45" [_thread_blocked, id=3656, stack(0x084e0000,0x08520000)]
0x04859400 JavaThread "Thread-44" [_thread_blocked, id=8924, stack(0x08460000,0x084a0000)]
0x04858c00 JavaThread "Thread-43" [_thread_blocked, id=7536, stack(0x083e0000,0x08420000)]
0x04858800 JavaThread "Thread-42" [_thread_blocked, id=4368, stack(0x08360000,0x083a0000)]
0x04858000 JavaThread "Thread-41" [_thread_blocked, id=8488, stack(0x082e0000,0x08320000)]
0x04857c00 JavaThread "Thread-40" [_thread_blocked, id=6112, stack(0x08260000,0x082a0000)]
0x04857400 JavaThread "Thread-39" [_thread_blocked, id=6060, stack(0x081e0000,0x08220000)]
0x04857000 JavaThread "Thread-38" [_thread_blocked, id=9200, stack(0x08160000,0x081a0000)]
0x04856800 JavaThread "Thread-37" [_thread_blocked, id=5476, stack(0x080e0000,0x08120000)]
0x04856000 JavaThread "Thread-36" [_thread_blocked, id=2828, stack(0x08060000,0x080a0000)]
0x04855c00 JavaThread "Thread-35" [_thread_blocked, id=8320, stack(0x07fe0000,0x08020000)]
0x04855400 JavaThread "Thread-34" [_thread_blocked, id=5668, stack(0x07f60000,0x07fa0000)]
0x04855000 JavaThread "Thread-33" [_thread_blocked, id=8316, stack(0x07ee0000,0x07f20000)]
0x04854800 JavaThread "Thread-32" [_thread_blocked, id=4836, stack(0x07e60000,0x07ea0000)]
0x04854400 JavaThread "Thread-31" [_thread_blocked, id=964, stack(0x07de0000,0x07e20000)]
0x04853c00 JavaThread "Thread-30" [_thread_blocked, id=4544, stack(0x07d60000,0x07da0000)]
0x04853400 JavaThread "Thread-29" [_thread_blocked, id=4388, stack(0x07ce0000,0x07d20000)]
0x04853000 JavaThread "Thread-28" [_thread_blocked, id=7204, stack(0x07c60000,0x07ca0000)]
0x04852800 JavaThread "Thread-27" [_thread_blocked, id=864, stack(0x07be0000,0x07c20000)]
0x0482f800 JavaThread "Thread-26" [_thread_blocked, id=6928, stack(0x07b60000,0x07ba0000)]
0x0482f400 JavaThread "Thread-25" [_thread_blocked, id=7692, stack(0x07ae0000,0x07b20000)]
0x0482ec00 JavaThread "Thread-24" [_thread_blocked, id=7196, stack(0x07a60000,0x07aa0000)]
0x0482e400 JavaThread "Thread-23" [_thread_blocked, id=7116, stack(0x079e0000,0x07a20000)]
0x0482e000 JavaThread "Thread-22" [_thread_blocked, id=4332, stack(0x07960000,0x079a0000)]
0x0482d800 JavaThread "Thread-21" [_thread_blocked, id=6780, stack(0x078e0000,0x07920000)]
0x0482d400 JavaThread "Thread-20" [_thread_blocked, id=5700, stack(0x07860000,0x078a0000)]
0x0482cc00 JavaThread "Thread-19" [_thread_blocked, id=6116, stack(0x077e0000,0x07820000)]
0x0482c800 JavaThread "Thread-18" [_thread_blocked, id=7824, stack(0x07760000,0x077a0000)]
0x0482c000 JavaThread "Thread-17" [_thread_blocked, id=9096, stack(0x076e0000,0x07720000)]
0x0482b800 JavaThread "Thread-16" [_thread_blocked, id=9144, stack(0x07660000,0x076a0000)]
0x0482b400 JavaThread "Thread-15" [_thread_blocked, id=5336, stack(0x075e0000,0x07620000)]
0x0482ac00 JavaThread "Thread-14" [_thread_blocked, id=2076, stack(0x07560000,0x075a0000)]
0x0482a800 JavaThread "Thread-13" [_thread_blocked, id=5300, stack(0x074e0000,0x07520000)]
0x0482a000 JavaThread "Thread-12" [_thread_blocked, id=4912, stack(0x07460000,0x074a0000)]
0x04829c00 JavaThread "Thread-11" [_thread_blocked, id=8512, stack(0x073e0000,0x07420000)]
0x04829400 JavaThread "Thread-10" [_thread_blocked, id=8772, stack(0x07360000,0x073a0000)]
0x04828c00 JavaThread "Thread-9" [_thread_blocked, id=4380, stack(0x072e0000,0x07320000)]
0x04828800 JavaThread "Thread-8" [_thread_blocked, id=6076, stack(0x07260000,0x072a0000)]
0x04828000 JavaThread "RMI Reaper" [_thread_blocked, id=6184, stack(0x071e0000,0x07220000)]
0x04801c00 JavaThread "Thread-7" [_thread_blocked, id=4168, stack(0x07160000,0x071a0000)]
0x0496a000 JavaThread "HSQLDB Timer @def14f" daemon [_thread_blocked, id=4616, stack(0x050e0000,0x05120000)]
0x03bd6c00 JavaThread "C3P0PooledConnectionPoolManager[identityToken->2x760f905j9tmy1l1yrpa|1e2c841]-HelperThread-#2" daemon [_thread_blocked, id=4136, stack(0x05060000,0x050a0000)]
0x03bd6400 JavaThread "C3P0PooledConnectionPoolManager[identityToken->2x760f905j9tmy1l1yrpa|1e2c841]-HelperThread-#1" daemon [_thread_blocked, id=8356, stack(0x04fe0000,0x05020000)]
0x03a05400 JavaThread "C3P0PooledConnectionPoolManager[identityToken->2x760f905j9tmy1l1yrpa|1e2c841]-HelperThread-#0" daemon [_thread_blocked, id=5404, stack(0x04f60000,0x04fa0000)]
0x03a04c00 JavaThread "C3P0PooledConnectionPoolManager[identityToken->2x760f905j9tmy1l1yrpa|1e2c841]-AdminTaskTimer" daemon [_thread_blocked, id=5860, stack(0x041c0000,0x04200000)]
0x042ae000 JavaThread "GC Daemon" daemon [_thread_blocked, id=5292, stack(0x04140000,0x04180000)]
0x03a66400 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=8056, stack(0x03fb0000,0x03ff0000)]
0x03a63c00 JavaThread "RMI TCP Accept-9090" daemon [_thread_in_native, id=2664, stack(0x03f30000,0x03f70000)]
0x03a42c00 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=8832, stack(0x03da0000,0x03de0000)]
0x00f56800 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=4600, stack(0x039a0000,0x039e0000)]
0x00f47400 JavaThread "C1 CompilerThread0" daemon [_thread_blocked, id=7060, stack(0x038f0000,0x03960000)]
0x00f46400 JavaThread "Attach Listener" daemon [_thread_blocked, id=3928, stack(0x03870000,0x038b0000)]
0x00f43000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=4864, stack(0x037f0000,0x03830000)]
0x00f3c000 JavaThread "Finalizer" daemon [_thread_blocked, id=6164, stack(0x03770000,0x037b0000)]
0x00f3a800 JavaThread "Reference Handler" daemon [_thread_blocked, id=9004, stack(0x036f0000,0x03730000)]
0x00eba400 JavaThread "main" [_thread_in_native, id=4904, stack(0x00d80000,0x00df0000)]
Other Threads:
0x00efd400 VMThread [stack: 0x03640000,0x036b0000] [id=5172]
0x03a68400 WatcherThread [stack: 0x04090000,0x04100000] [id=9092]
VM state:synchronizing (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x00eb8780] Threads_lock - owner thread: 0x00efd400
Heap
def new generation   total 142208K, used 109631K [0x10340000, 0x1a9e0000, 0x1a9e0000)
eden space 113792K, 90% used [0x10340000, 0x167a60c0, 0x17260000)
from space 28416K, 24% used [0x18e20000, 0x194c9cd8, 0x1a9e0000)
to   space 28416K,   0% used [0x17260000, 0x17260000, 0x18e20000)
tenured generation   total 341376K, used 148495K [0x1a9e0000, 0x2f740000, 0x2f740000)
   the space 341376K, 43% used [0x1a9e0000, 0x23ae3f10, 0x23ae4000, 0x2f740000)
compacting perm gen total 145408K, used 59874K [0x2f740000, 0x38540000, 0x38540000)
   the space 145408K, 41% used [0x2f740000, 0x331b88a8, 0x331b8a00, 0x38540000)
    ro space 10240K, 51% used [0x38540000, 0x38a73000, 0x38a73000, 0x38f40000)
    rw space 12288K, 55% used [0x38f40000, 0x395de4f8, 0x395de600, 0x39b40000)
Code Cache [0x013b0000, 0x02378000, 0x033b0000)
total_blobs=6549 nmethods=6302 adapters=179 free_code_cache=17026624 largest_free_block=384
Dynamic libraries:
0x00400000 - 0x00417000 C:\Program Files (x86)\Tomcat\bin\Tomcat.exe
0x771c0000 - 0x77340000 C:\Windows\SysWOW64\ntdll.dll
0x76ac0000 - 0x76bd0000 C:\Windows\syswow64\kernel32.dll
0x752f0000 - 0x75336000 C:\Windows\syswow64\KERNELBASE.dll
0x758f0000 - 0x75990000 C:\Windows\syswow64\ADVAPI32.dll
0x75830000 - 0x758dc000 C:\Windows\syswow64\msvcrt.dll
0x74e10000 - 0x74e29000 C:\Windows\SysWOW64\sechost.dll
0x75710000 - 0x75800000 C:\Windows\syswow64\RPCRT4.dll
0x74d20000 - 0x74d80000 C:\Windows\syswow64\SspiCli.dll
0x74d10000 - 0x74d1c000 C:\Windows\syswow64\CRYPTBASE.dll
0x75ac0000 - 0x7670a000 C:\Windows\syswow64\SHELL32.dll
0x75290000 - 0x752e7000 C:\Windows\syswow64\SHLWAPI.dll
0x74d80000 - 0x74e10000 C:\Windows\syswow64\GDI32.dll
0x76760000 - 0x76860000 C:\Windows\syswow64\USER32.dll
0x758e0000 - 0x758ea000 C:\Windows\syswow64\LPK.dll
0x74e30000 - 0x74ecd000 C:\Windows\syswow64\USP10.dll
0x75340000 - 0x753a0000 C:\Windows\system32\IMM32.DLL
0x751c0000 - 0x7528c000 C:\Windows\syswow64\MSCTF.dll
0x6d810000 - 0x6dac0000 C:\Program Files (x86)\Java\jre6\bin\client\jvm.dll
0x74140000 - 0x74172000 C:\Windows\system32\WINMM.dll
0x7c340000 - 0x7c396000 C:\Windows\system32\MSVCR71.dll
0x740f0000 - 0x7413c000 C:\Windows\system32\apphelp.dll
0x6d7c0000 - 0x6d7cc000 C:\Program Files (x86)\Java\jre6\bin\verify.dll
0x6d330000 - 0x6d34f000 C:\Program Files (x86)\Java\jre6\bin\java.dll
0x6d800000 - 0x6d80f000 C:\Program Files (x86)\Java\jre6\bin\zip.dll
0x76bd0000 - 0x76d2c000 C:\Windows\syswow64\ole32.dll
0x6d560000 - 0x6d569000 C:\Program Files (x86)\Java\jre6\bin\management.dll
0x6d610000 - 0x6d623000 C:\Program Files (x86)\Java\jre6\bin\net.dll
0x753e0000 - 0x75415000 C:\Windows\syswow64\WS2_32.dll
0x75990000 - 0x75996000 C:\Windows\syswow64\NSI.dll
0x74880000 - 0x748bc000 C:\Windows\system32\mswsock.dll
0x747d0000 - 0x747d6000 C:\Windows\System32\wship6.dll
0x748d0000 - 0x748e0000 C:\Windows\system32\NLAapi.dll
0x748c0000 - 0x748d0000 C:\Windows\system32\napinsp.dll
0x74830000 - 0x74874000 C:\Windows\system32\DNSAPI.dll
0x74820000 - 0x74828000 C:\Windows\System32\winrnr.dll
0x747e0000 - 0x747e5000 C:\Windows\System32\wshtcpip.dll
0x74800000 - 0x7481c000 C:\Windows\system32\IPHLPAPI.DLL
0x747f0000 - 0x747f7000 C:\Windows\system32\WINNSI.DLL
0x747c0000 - 0x747c6000 C:\Windows\system32\rasadhlp.dll
0x74780000 - 0x747b8000 C:\Windows\System32\fwpuclnt.dll
0x74750000 - 0x74766000 C:\Windows\system32\CRYPTSP.dll
0x744d0000 - 0x7450b000 C:\Windows\system32\rsaenh.dll
0x74030000 - 0x7403b000 C:\Windows\system32\profapi.dll
0x6d7a0000 - 0x6d7a8000 C:\Program Files (x86)\Java\jre6\bin\sunmscapi.dll
0x759a0000 - 0x75abd000 C:\Windows\syswow64\CRYPT32.dll
0x753d0000 - 0x753dc000 C:\Windows\syswow64\MSASN1.dll
0x6d630000 - 0x6d639000 C:\Program Files (x86)\Java\jre6\bin\nio.dll
0x10000000 - 0x10047000 C:\Windows\System32\corojdk11.dll
0x74ed0000 - 0x74f5f000 C:\Windows\syswow64\OLEAUT32.dll
0x75420000 - 0x754a3000 C:\Windows\syswow64\CLBCatQ.DLL
0x744c0000 - 0x744ce000 C:\Windows\system32\RpcRtRemote.dll
0x74180000 - 0x741df000 C:\Windows\system32\SXS.DLL
0x0b820000 - 0x0b853000 C:\Program Files (x86)\Tomcat\bin\HASPJava.dll
0x0b860000 - 0x0bb4d000 C:\Program Files (x86)\Tomcat\bin\hasp_windows_87368.dll
0x74c50000 - 0x74c57000 C:\Windows\system32\WSOCK32.DLL
0x6d000000 - 0x6d14c000 C:\Program Files (x86)\Java\jre6\bin\awt.dll
0x73c20000 - 0x73c71000 C:\Windows\system32\WINSPOOL.DRV
0x74430000 - 0x744b4000 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\COMCTL32.dll
0x6eb40000 - 0x6eb53000 C:\Windows\system32\DWMAPI.DLL
0x6d230000 - 0x6d286000 C:\Program Files (x86)\Java\jre6\bin\fontmanager.dll
0x77190000 - 0x77195000 C:\Windows\system32\PSAPI.DLL
VM Arguments:
jvm_args: -Dcatalina.home=C:\Program Files (x86)\Tomcat -Dcatalina.base=C:\Program Files (x86)\Tomcat -Djava.endorsed.dirs=C:\Program Files (x86)\Tomcat\endorsed -Djava.io.tmpdir=C:\Program Files (x86)\Tomcat\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files (x86)\Tomcat\conf\logging.properties -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=c:\progra~2\tomcat -Xms500m -Xmx500m -XX:SurvivorRatio=4 -XX:PermSize=143m -XX:MaxPermSize=143m -Xss200k -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:TomcatGarbageCollection -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote=true
java_command: <unknown>
Launcher Type: generic
Environment Variables:
PATH=Y:\Legato\nsr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Tivoli\IBM\ITM\bin;c:\Tivoli\IBM\ITM\InstallITM;c:\Tivoli\IBM\ITM\TMAITM6;C:\Program Files (x86)\Tomcat\lib
USERNAME=NCDWSMNASP0101$
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 44 Stepping 2, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows NT 6.1 , 64 bit Build 7601 Service Pack 1
CPU:total 4 (1 cores per cpu, 1 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt
Memory: 4k page, physical 4193848k(1041944k free), swap 8385852k(5027848k free)
vm_info: Java HotSpot(TM) Client VM (20.45-b01) for windows-x86 JRE (1.6.0_45-b06), built on Mar 26 2013 13:40:03 by "java_re" with MS VC++ 7.1 (VS2003)
time: Sun Feb 09 19:41:33 2014
elapsed time: 31207 seconds

Thanks a lot.
HASPJava.dll is used by verification License and is invoked less and can't use a lot of native memory.
Our business is communicating between java and COM component. In order to implement it, we used JavaCom to generate java class for COM component.
Memory of COM component is little, but Native Memory is high.
Who used JavaCom and did you meet this problem?
Please give me some suggestions. Thanks a lot.

Memory management while implementing JNI interfaces.

The assumption here is that java code calls a C function from a
shared library in Linux.
How should memory management be done in the native code called
from Java using a JNI interface?
What role does the Garbage Collector play in handling memory that
was allocated in the native C code?
If I allocate memory using malloc() in the C program, should I
explicitly free it? Will the GC take care of it?
Does anyone have an idea of how memory management be done while
implementing a JNI interface?
Thanks,
Nisahnt

NishantMungse wrote:
The assumption here is that java code calls a C function from a
shared library in Linux.
How should memory management be done in the native code called
from Java using a JNI interface?
C: Alloc something giving a pointer
C: Return pointer to Java as a long.
C: As needed methods take a long parameter and cast to correct pointer.
C: Provide a destroy() method that takes a long, casts to correct pointer and deallocates correctly.
Java: class keeps long
Java: As needed JNI methods are passed long
Java: Provide a destroy() method which passes long to C destroy() method if long is not zero. After call set long to zero.
Java: Optional: Add a finalizer. It calls destroy()
Last step is optional if your programming environment is strict AND the usage of the class has a restricted scope.
The above assumes that you are going to use the memory in a 'normal' way. For instance there allocations are relatively small, and exist for short amounts of time. If that isn't true then you might need to tune the usage in much the same way that you might if you had a Java class that consumed a large amount of memory.
What role does the Garbage Collector play in handling memory that
was allocated in the native C code?
It doesn't.
At some point it can interfere with the heap though.
If I allocate memory using malloc() in the C program, should I
explicitly free it? Will the GC take care of it?
You must explicitly free it.
Does anyone have an idea of how memory management be done while
implementing a JNI interface?See above.

Memory manager - Profiler

I will have several questions about memory management,
garbage collection by Flash.
First of all can anyone explain what is the link between the
memory usage of the profiler and the System.totalMemory value.
I use a module to display the totalMemory value evolution
with a timeline chart (get the totalMemory value every 0.5 second
and keeping only last 300 values).
Here what I get : after about 4 hours of time running, the
memory usage peak is about 24 Mbytes, BUT the System.totalMemory is
about 600 Mbytes !!
Before trying to understand why I have this memory
consumption, I would like to understand the difference between what
the profiler is measuring (24 Mbytes) and the memory used by the
Flash Player (600 Mbytes).
Thanks

This is a loaded question but let me try to take a stab at it:
First, let's right away eliminate the 'Minimize Application' issue; the memory that goes way down to 1 meg is the actual Real Memory being used by the Application, by minimizing it, you are putting all the application memory space into the Windows swap file. When you restore the application, then you will see the value grow again back to where it was by taking the swapped out pages back into real memory.
The difference between the memory profiler and the task manager could be drastic in terms of consumption, the memory profiler is tracking only the java objects allocated and freed by your application, the task manager is look at the Windows Process as a whole, which contains a Virtual Machine that needs memory to store loaded classes, internal data and application heap (which are the actual java objects). The application heap will be usually far bigger than the cumulative total number of objects in your application.
A usual way to use the memory profiler is to, by running it on your application, take a snapshot of the memory before an expensive operation, perform the operation, then take a snapshot again and see what is left to make sure no leaks are being created.
In order to find out why your expensive operation is so... expensive, is to increase the granularity of the operation up to a point where you will get to the few sections of code that allocate all that memory.
Hope that helps,
Michel

Is it possible to create the memory for a Java object in C/C++?

Is it possible to have a C/C++ program allocate some memory, then have JNI use that memory for primitive java objects (such an array of bytes) that are passed to Java objects ?
I would like to allocate a region of memory in C++, then give that memory to a Java object (via some kind of JNI type) and have that Java object fill the memory region with data.
My impression from reading the JNI API and the few examples I've looked at is "No", there is a strict boundary between C++ and JNI as regards memory management. There may be serious implications as to why what I'm suggesting is not feasible, I am not enough of a JNI expert to know yet, and would greatly appreciate any input/comment.
Many thanks,
Colm.

No, you cannot. However, writing your JNI code you should not use memory of Local Heap (if it possible). Because Local Heap Memory used also by JVM. I have developed tools that generate C++ wrappers for JNI code. In these wrappers I use mainly Global/Virtual Memory. I also reduce to minimum creation of local/global references, as it is affects to JVM memory use. If you are writing JNI code under MS Windows then you can try my tools that automate JNI code writing:
http://simtel.net/product.php[id]93174[SiteID]simtel.net
http://simtel.net/product.php[id]94368[SiteID]simtel.net
Now I am developing this tool for .Net. In two weeks it will be finished.

Memory management in glassfish v2

Hello! I have a few questions about EJB 3.0 and specifically GlassFish V2.
1) Do all of my EJB instances run in the same process with glassfish server? (when I start glassfish domain and run my EE java client application, there is only two java.exe processes in Task Manager).
2) My javaee application needs a lot of memory... when I start processing (EJB method) I see in Task Manager that java.exe consumes more than 250Mb. When I close my javaee client application I see that this memory doesn't want to return back to OS. I think it is not good... I want GlassFish to be running 24 hours a day, why this memory doesn't return back to OS when server is idle?
Help me please. Sorry if this subject was already discussed (I couldn't find it here). Thank you.

I rooted my tablet, and when looking at the processor speed in SetCPU, Sony uses a governor for power management that makes the tablet run jagged... I changed the power governor to ondemand, and got MUCH better smoothness and performance, while not sacrificing my battery life. You should try it out, maybe that'll help with games and such.

Use JNI application has memory manager, feasible?

Hi,
This is an attempt to circumvent javas poor memory management capabilities. Since java is unable to allocate memory dynamically (*) I'm thinking of writing a native library capable of allocating memory and then allowing java applications to stow away data in this area. The application would be able to access the memory directly through some java.nio.ByteArray-type implementation.
The java application would be responsible for allocating and deallocating, reading and writing data.
Is this feasible? Has anyone done this already? I guess a JNI is solution would be pretty straightforward?
(...this will be my first experience with JNI)
(*) Xmx option can be used assuming you know beforehand the memory requirements.

Hi,
This is feasible since JNative already does this.
See Pointer and MemoryBlockFactory classes to do this.
--Marc (http://jnative.sf.net)

Confusion about Automatic Shared Memory Management

Hi,
Oracle Database 10g includes the Automatic Shared Memory Management feature which simplifies the SGA memory management significantly. To use Automatic Shared Memory Management, we have to set the SGA_TARGET initialization parameter to a nonzero value and the STATISTICS_LEVEL initialization parameter to TYPICAL or ALL.
Oracle Database 10g Rel. 2 documentation, in some places, says that:
If SGA_TARGET is specified, then the following FIVE memory pools are automatically sized:
* Buffer cache (DB_CACHE_SIZE)
* Shared pool (SHARED_POOL_SIZE)
* Large pool (LARGE_POOL_SIZE)
* Java pool (JAVA_POOL_SIZE)
* Streams pool (STREAMS_POOL_SIZE)
Ref.:
1. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams192.htm
2. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/memory.htm
3. Oracle Database 10g: New Features for Administrators - Student Guide
But in some places I found the following:
If SGA_TARGET is specified, then the buffer cache (DB_CACHE_SIZE), Java pool (JAVA_POOL_SIZE), large pool (LARGE_POOL_SIZE), and shared pool (SHARED_POOL_SIZE) memory pools are automatically sized.
Here you can see that Streams Pool is not included in the automatically sized pools.
Ref.:
1. http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14211/build_db.htm#sthref252
Also, according to Oracle Press' Book "OCP Oracle Database 10g: New Features for Administrators Exam Guide:
Under Automatic Shared Memory Management, the database manages the
following FOUR major components of the SGA, also known as the auto-tuned SGA
parameters:
■ Buffer cache (DB_CACHE_SIZE)
■ Shared pool (SHARED_POOL_SIZE)
■ Large pool (LARGE_POOL_SIZE)
■ Java pool (JAVA_POOL_SIZE)
It is important to understand that even under Automatic Shared Memory
Management, you still need to configure any SGA component other than the four
auto-tuned components. Following are the manually sized components of the SGA:
■ Redo Log Buffer
■ The KEEP and RECYCLE buffer caches (if specified)
■ The nonstandard block size buffer caches (if specified)
■ The new Streams pool SGA component
■ The new Oracle Storage Management (OSM) buffer cache, which is meant
for the optional ASM instance
Now my question is "IS Streams Pool an auto-tuned SGA parameter?"
Thanks in advance.
--Khan.

Hi,
I would advise you to read Document I.D. Note:295626.1 on Oracle Metalink.
It states that
When enabled, it lets Oracle decide of the right size for some components of the SGA:
SHARED POOL
LARGE POOL
JAVA POOL
DB CACHE (using the DB_BLOCK_SIZE value)
The SGA_TARGET value will therefore define the memory size sharable between auto-tuned and manual parameters.
The manual parameters are:
DB_<KEEP/RECYCLE>CACHESIZE
DB_nK_CACHE_SIZE (non default block size)
LOG_BUFFER
FIXED SGA
STREAMS_POOL_SIZE
Adith

What is difference between 32 bit and 64 bit sql server memory management

What is difference between 32 bit and 64 bit sql server memory management
Thanks
Shashikala

This is the basic difference...check if helps:
A 32-bit CPU running 32-bit software (also known as the x86 platform) is so named because it is based on an architecture that can manipulate values that are up to 32 bits in length. This means that a 32-bit memory pointer can store a value between 0 and
4,294,967,295 to reference a memory address. This equates to a maximum addressable space of 4GB on 32-bit platforms
On the other hand 64-bit limit of 18,446,744,073,709,551,616, this number is so large that in memory/storage terminology it equates to 16 exabytes. You don’t come across that term very often, so to help understand the scale, here is the value converted to
more commonly used measurements: 16 exabytes = 16,777,216 petabytes (16 million PB)➤ 17,179,869,184 terabytes (17 billion TB)➤ 17,592,186,044,416 gigabytes (17 trillion GB)➤
As you can see, it is signiﬁcantly larger than the 4GB virtual address space usable in 32-bit systems; it’s so large in fact that any hardware capable of using it all is sadly restricted to the realm of science ﬁction. Because of this, processor manufacturers
decided to only implement a 44-bit address bus, which provides a virtual address space on 64-bit systems of 16TB. This was regarded as being more than enough address space for the foreseeable future and logically it’s split into an 8TB range for user mode
and 8TB for kernel mode. Each 64-bit process running on an x64 platform will be able to address up to 8TB of VAS.
Please click the Mark as answer button and vote as helpful if this reply solves your problem

Memory management in Java

Similar Messages

Maybe you are looking for