[JS] $.gc() - garbage collection, etc.

Hello everyone, bear with me for all the questions.
$.gc() - Initiates garbage collection in the JavaScript engine.
Ok, maybe I have a fundamental misunderstanding of things here, but I am wanting to understand a few things:
I was wanting to know if $.gc() can be called and executed outside of running scripts directly from with in the ESTK toolkit? The reason I ask is that its listed in the tools guide but not the javascript reference. I know things like $.writeln() only seem to apply/display from with in the ETSK toolkit, is it still executed otherwise silently when it appears in a script, $.sleep() works fine when used. So what about $.gc(), can I call it and have it execute from within my scripts outside of running them via the ETSK toolkit?
Is there a way to test if its in fact being called, executed, working? I have seen people talking about calling it twice and doubling up, $.gc() $.gc(), thus does it even work, or is it just a fabled mythical thing.
Do codes when executed outside the ETSK toolkit get funneled through the same javascript runtime engine that they do when executing from with in the ETSK toolkit? Is it all the same and the ETSK toolkit is just Adobe's GUI for writing, debugging, targeting different api's for the various programs with in the same underlying engine?
Does ScriptBay tap into and use this same underlying framework? Does it do anything inherently on its own for garbage collection? (since it can run scripts sequentially, repetitively, etc..)
Does anyone know what embedded javascript runtime/engine Adobe is using? This would be beneficial for any specific optimizations that can be considered or kept in mind in general based on the specific JS engine thats implemented when coding.
So aside from the mythical $.gc() , what other best practices for garbage collection should be considered? I know people suggest wrapping your codes in a function, talk of #targetengine (saw in InDesign forum), etc… are there any other common do's and dont's, best practices pertaining specifically to illustrator? Granted I can find a lot about Javascript in general across the web but what about how it applies to Illustrator, its api, limitations, performance, garbage collection, etc..
Thanks. ;-)
Again, sorry for all the questions, I am still trying to continue to wrap my head around different aspects of this whole thing. Thanks everyone for any feedback your able to offer and provide. Many thanks in advance, its greatly appreciated. Thanks again.

I can't answer or help with all of those… Here are my thoughts… The dollar object properties and functions can be called on by script from AI, BR, ID & PS… They are NOT restricted for use in the ESTK tookit. Yeah $.writeln() would write to the console if the toolkit were open if NOT then it will probably launch it… So remove or comment these out. As you can see from $.sleep() it does what it says when run in the host app. #targetengine is exclusive to ID this app can have multi-instances ( or something like that ). The other apps have 1 engine and thats it. AI's engine is persistent so wrapping your code is good practice I do this for BR & PS too… See…
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/illustrator/scrip ting/readme_cs5.txt
As for garbage collection I've never fould the need to use it… I see some like to set variables back to null but again I don't do this…
You would have been better off asking this question in the ID scripting forum… There are several people there who are better qualified to answer some of this…

Similar Messages

  • Hotspot core dumping during JVM garbage collection ?

    We have an application which calls a 3rd party supplied server API which has recently been upgraded to use Java 1.5
    We are getting the following error reported by our client application. The application is also now running Java 1.5 but references many classes in jar files which would have quite old code in.
    The supplier of the API has stated that the problem requires us to recompile all our jar files using v 1.5 ( including things like jconnect and jms ?!?!? ). This sounds like a bit of a cop-out to me, not to mention being impossible since we don't have the source for things like jconnect.
    I suspect that there is a garbage collection problem at the bottom of all this, but I'm not sure how I can "prove" this, nor do I currently have any real clue as to how to fix any GC problem that may exist.
    The application is supposed to wait for a message on a MQSeries queue and then transforms it via Xalan XSLT and sends it to a Server application. I've tried playing around with heap sizes etc but that just seems to make it worse. If I leave it at the settings that the previous version used then the client at least manages to process a couple of messages before core dumping. There doesn't seem to be a consistent trigger event to cause the core dump ( it's not a message arriving on a queue for example ) but it does seem to be fairly consistent timewise, i.e. after
    Any ideas gratefully accepted.
    Here's a logfile excerpt from my applications showing the Hotspot error message :
    =====================================================================================
    08-Jul-2008 10:01:05 Waiting for messages from COLT.BBFS
    08-Jul-2008 10:02:05 Waiting for messages from COLT.BBFS
    08-Jul-2008 10:03:05 Waiting for messages from COLT.BBFS
    405.815: [GC [PSYoungGen: 17331K->9244K(37632K)] 111702K->103615K(192128K), 0.1615910 secs]
    405.977: [Full GC#
    # An unexpected error has been detected by HotSpot Virtual Machine:
    #  SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
    # Problematic frame:
    # V  [libjvm.so+0x141348]
    # An error report file with more information is saved as hs_err_pid2600.log
    # If you would like to submit a bug report, please visit:
    # http://java.sun.com/webapps/bugreport/crash.jsp
    =====================================================================================
    The logfile referred to in the error message contains the following.
    =====================================================================================
    # An unexpected error has been detected by HotSpot Virtual Machine:
    # SIGBUS (0xa) at pc=0xfe141348, pid=2600, tid=8
    # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
    # Problematic frame:
    # V [libjvm.so+0x141348]
    --------------- T H R E A D ---------------
    Current thread (0x001484d8): VMThread [id=8]
    siginfo:si_signo=10, si_errno=0, si_code=1, si_addr=0x0000080f
    Registers:
    O0=0x00487588 O1=0xfe7d6454 O2=0x000079b0 O3=0x00007800
    O4=0x00008868 O5=0x00147d48 O6=0xf8781460 O7=0xfe0f7938
    G1=0xe52aaae8 G2=0x00000003 G3=0x00000003 G4=0x001484d8
    G5=0xf8781d98 G6=0x00000002 G7=0xf8781d98 Y=0x805683e2
    PC=0xfe141348 nPC=0xfe14134c
    Top of Stack: (sp=0xf8781460)
    0xf8781460: fe786000 00c6ba20 fe10013c e54bab68
    0xf8781470: 0000080f e54bab6c 0000080f 00000004
    0xf8781480: 00487588 00000134 e54bab6c 00000004
    0xf8781490: 00000001 00000000 f87814c0 fe17aef4
    0xf87814a0: fe6485b4 fe7d899c 001484d8 0011da40
    0xf87814b0: 00148988 00148c10 00148d7c f8781880
    0xf87814c0: 007c3389 007c3c0e 00000f87 00008868
    0xf87814d0: 00008800 00487588 fe141310 fe7d6454
    Instructions: (pc=0xfe141348)
    0xfe141338: ec 06 c0 1a 80 a5 a0 00 22 40 00 0a ba 07 60 01
    0xfe141348: f2 05 a0 00 ae 0e 60 03 80 a5 e0 03 22 40 00 05
    Stack: [0xf8702000,0xf8781d98), sp=0xf8781460, free space=509k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
    V [libjvm.so+0x141348]
    V [libjvm.so+0x17aefc]
    V [libjvm.so+0x2d557c]
    V [libjvm.so+0x300ef8]
    V [libjvm.so+0x301e84]
    V [libjvm.so+0x2ff950]
    V [libjvm.so+0x29df30]
    V [libjvm.so+0x362b44]
    V [libjvm.so+0x6436f0]
    VM_Operation (0xe03012b0): parallel gc system gc, mode: safepoint, requested by thread 0x0031bca0
    --------------- P R O C E S S ---------------
    Java Threads: ( => current thread )
    0x00b2c028 JavaThread "Thread-4" [_thread_in_native, id=85]
    0x007f5048 JavaThread "Thread-0" [_thread_blocked, id=84]
    0x00c27cf0 JavaThread "Notification Delivery" [_thread_blocked, id=81]
    0x0026fa08 JavaThread "RMI LeaseChecker" daemon [_thread_blocked, id=73]
    0x00821048 JavaThread "RMI RenewClean-[162.11.2.32:44425]" daemon [_thread_blocked, id=70]
    0x0031bca0 JavaThread "GC Daemon" daemon [_thread_blocked, id=67]
    0x00cd5d28 JavaThread "RMI Reaper" [_thread_blocked, id=66]
    0x003c9300 JavaThread "Timer-0" daemon [_thread_blocked, id=65]
    0x00929fe0 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=64]
    0x0089bf18 JavaThread "SeedGenerator Thread" daemon [_thread_blocked, id=42]
    0x00c47248 JavaThread "Pool thread #7" daemon [_thread_blocked, id=38]
    0x00c466a0 JavaThread "Pool thread #6" daemon [_thread_blocked, id=37]
    0x00311850 JavaThread "Pool thread #5" daemon [_thread_blocked, id=36]
    0x00287a40 JavaThread "Pool thread #4" daemon [_thread_blocked, id=35]
    0x00286e98 JavaThread "Pool thread #3" daemon [_thread_blocked, id=34]
    0x00c134b0 JavaThread "Pool thread #2" daemon [_thread_blocked, id=33]
    0x00ad09e0 JavaThread "Pool thread #1" daemon [_thread_blocked, id=32]
    0x00286cd8 JavaThread "PoolThreadManager" daemon [_thread_blocked, id=31]
    0x00c129e0 JavaThread "Channel Reaper" daemon [_thread_blocked, id=30]
    0x00c669e8 JavaThread "ORB Daemon Thread" daemon [_thread_blocked, id=29]
    0x00b10170 JavaThread "Worker for ServerProtocol: (iiop) /0.0.0.0:20168" daemon [_thread_blocked, id=22]
    0x008a17e0 JavaThread "Syn~ Client" daemon [_thread_blocked, id=21]
    0x003dc378 JavaThread "PoolScavenger0" daemon [_thread_blocked, id=20]
    0x0015a928 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=15]
    0x00159880 JavaThread "CompilerThread1" daemon [_thread_blocked, id=14]
    0x00158a18 JavaThread "CompilerThread0" daemon [_thread_blocked, id=13]
    0x00157b98 JavaThread "AdapterThread" daemon [_thread_blocked, id=12]
    0x00156dc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=11]
    0x0014ccd8 JavaThread "Finalizer" daemon [_thread_blocked, id=10]
    0x0014ad90 JavaThread "Reference Handler" daemon [_thread_blocked, id=9]
    0x00038238 JavaThread "main" [_thread_in_native, id=1]
    Other Threads:
    =>0x001484d8 VMThread [id=8]
    0x0015c3b0 WatcherThread [id=16]
    VM state:at safepoint (normal execution)
    VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
    [0x00037728/0x00037758] Threads_lock - owner thread: 0x001484d8
    [0x00033650/0x00037ba8] Heap_lock - owner thread: 0x0031bca0
    Heap
    PSYoungGen total 37632K, used 9244K [0xf2eb0000, 0xf7ba0000, 0xf8400000)
    eden space 28352K, 0% used [0xf2eb0000,0xf2eb0000,0xf4a60000)
    from space 9280K, 99% used [0xf4a60000,0xf5367080,0xf5370000)
    to space 25216K, 0% used [0xf6300000,0xf6300000,0xf7ba0000)
    PSOldGen total 154496K, used 94371K [0xe8400000, 0xf1ae0000, 0xf2eb0000)
    object space 154496K, 61% used [0xe8400000,0xee028e78,0xf1ae0000)
    PSPermGen total 35584K, used 18260K [0xe4400000, 0xe66c0000, 0xe8400000)
    object space 35584K, 51% used [0xe4400000,0xe55d5158,0xe66c0000)
    Dynamic libraries:
    0x00010000      /dsdvlp/java/jvm/jdk1.5.0_03/bin/java
    0xff350000      /usr/lib/libthread.so.1
    0xff340000      /usr/lib/libdl.so.1
    0xff200000      /usr/lib/libc.so.1
    0xff390000      /usr/platform/SUNW,Sun-Fire-880/lib/libc_psr.so.1
    0xfe000000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server/libjvm.so
    0xff1e0000      /usr/lib/libsocket.so.1
    0xff2d0000      /usr/lib/libsched.so.1
    0xff1b0000      /usr/lib/libCrun.so.1
    0xff160000      /usr/lib/libm.so.1
    0xff080000      /usr/lib/libnsl.so.1
    0xff060000      /usr/lib/libmp.so.2
    0xff030000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/native_threads/libhpi.so
    0xfdfc0000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libverify.so
    0xfdf80000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libjava.so
    0xfdf50000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libzip.so
    0xfb7e0000      /usr/lib/locale/en_GB.ISO8859-1/en_GB.ISO8859-1.so.2
    0xe4190000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/libnet.so
    0xe3bd0000      /dsdvlp/lib/5/libSolarisNatives.so
    0xe3e90000      /dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/librmi.so
    VM Arguments:
    jvm_args: -Djava.ext.dirs=/dsdvlp/java/tmijar/firs7/lib/cli:/dsdvlp/java/tmijar/firs7/lib/cli/ext:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB:/dsdvlp/java/tmijar/firs7/lib/cmn/OpenORB/ext:/dsdvlp/java/tmijar/firs7/lib/cmn:/dsdvlp/java/tmijar/firs7/lib/cmn/ext:/dsdvlp/java/tmijar/firs7/daemonlib -Duser.dir=/dsdvlp/java/tmijar/firs7 -Dopenorb.config=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB/config/SynOpenORB.xml -Dopenorb.home=file:/dsdvlp/java/tmijar/firs7/configs/OpenORB -Dcom.coexis.syn.general.orbbinding=com.coexis.syn.general.orbbinding.openorb.OpenORBBinding_1_4 -Dsun.rmi.dgc.client.gcInterval=360000 -Dsun.rmi.dgc.server.gcInterval=360000000 -Xms32m -Xmx256m -Dcom.coexis.syn.clientcommandsconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/clientcommands.xml -Dcom.coexis.syn.clientconfiglocation=file://localhost//dsdvlp/java/tmijar/firs7/configs/fsbbtd_client.xml -XX:+PrintGCTimeStamps -XX:+PrintGCDetails
    java_command: com.coexis.syn.mqmessaging.daemon.RunDaemon -p /dsdvlp/bin/5/lndsfsd_fsbbtd.properties start
    Environment Variables:
    JAVA_HOME=/dsdvlp/java/jvm/jdk150
    CLASSPATH=.:/dsdvlp/java/jar/jconnect520.jar:/dsdvlp/java/jar/vbjapp340.jar:/dsdvlp/java/jar/vbjorb340.jar:/dsdvlp/java/jar/javax_jndi120.jar
    PATH=/usr/local/etc:/usr/lang:/usr/openwin/bin:/usr/ucb:/bin:/usr/etc:/usr/local/5/bin:/dsdvlp/bin/5:/dsdvlp/bin/4:/home/app/sybase/5/bin:/home/app/sybase/5/localscripts:/home/app/sybase/5/sqr:/home/app/lang:/home/app/lang/SC2.0.1:/usr/ccs/bin:/usr/local/opt/Acrobat3/bin:/dsdvlp/bin:.
    LD_LIBRARY_PATH=/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc/server:/dsdvlp/java/jvm/jdk1.5.0_03/jre/lib/sparc:/dsdvlp/java/jvm/jdk1.5.0_03/jre/../lib/sparc:/usr/lib:/usr/openwin/lib:/usr/local/5/lib:/dsdvlp/lib/5:/dstest/lib/5:/home/app/sybase/5/lib:/dstest/cats/sun4/lib:/tmitest/Opus/opus/lib
    SHELL=/bin/csh
    DISPLAY=CLI00184.mfil.local:1.0
    OS=5
    --------------- S Y S T E M ---------------
    OS: Solaris 8 2/02 s28s_u7wos_08a SPARC
    Copyright 2002 Sun Microsystems, Inc. All Rights Reserved.
    Assembled 18 December 2001
    uname:SunOS 5.8 Generic_117350-20 sun4u (T1 libthread)
    rlimit: STACK 8192k, CORE 9216k, NOFILE 4096, AS infinity
    load average:2.24 2.67 2.68
    CPU:total 4 has_v8, has_v9, has_vis1, has_vis2, is_ultra3
    Memory: 8k page, physical 8388608k(166384k free)
    vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for solaris-sparc, built on Apr 13 2005 03:31:26 by unknown with unknown Workshop:0x550

    The very first suggestion I have is to move your VM to a more recent update of 1.5.0.
    It looks like you are crashing with 5.0u3, and I'm pretty sure 5.0u16 is available. You
    don't want to waste your time chasing a bug that's already been fixed.

  • High Eden Java Memory Usage/Garbage Collection

    Hi,
    I am trying to make sure that my Coldfusion Server is optomised to the max and to find out what is normal limits.
    Basically it looks like at times my servers can run slow but it is possible that this is caused by a very old bloated code base.
    Jrun can sometimes have very high CPU usage so I purchased Fusion Reactor to see what is going on under the hood.
    Here are my current Java settings (running v6u24):
    java.args=-server -Xmx4096m -Xms4096m -XX:MaxPermSize=256m -XX:PermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.io.useCanonCaches=false -XX:+UseParallelGC -Xbatch ........
    With regards Memory, the only memory that seems to be running a lot of Garbage Collection is the Eden Memory Space. It climbs to nearly 1.2GB in total just under every minute at which time it looks like GC kicks in and the usage drops to about 100MB.
    Survivor memory grows to about 80-100MB over the space of 10 minutes but drops to 0 after the scheduled full GC runs. Old Gen memory fluctuates between 225MB and 350MB with small steps (~50MB) up or down when full GC runs every 10 minutes.
    I had the heap set to 2GB initally in total giving about 600MB to the Eden Space. When I looked at the graphs from Fusion Reactor I could see that there was (minor) Garbage Collection about 2-3 times a minute when the memory usage maxed out the entire 600MB which seemed a high frequency to my untrained eye. I then upped the memory to 4GB in total (~1.2GB auto given to Eden space) to see the difference and saw that GC happened 1-2 times per minute.
    Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often? i.e do these graphs look normal?
    Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
    Any other advice for performance improvements would be much appreciated.
    Note: These graphs are not from a period where jrun had high CPU.
    Here are the graphs:
    PS Eden Space Graph
    PS Survivor Space Graph
    PS Old Gen Graph
    PS Perm Gen Graph
    Heap Memory Graph
    Heap/Non Heap Memory Graph
    CPU Graph
    Request Average Execution Time Graph
    Request Activity Graph
    Code Cache Graph

    Hi,
    >Is it normal in Coldfusion that the Eden memory would grow so quickly and have garbage collection run so often?
    Yes normal to garbage collect Eden often. That is a minor garbage collection.
    >Also should I somehow redistribute the memory available to give the Eden memory more since it seems to be where all the action is?
    Sometimes it is good to set Eden (Eden and its two Survivor Spaces combined make up New or Young Generation part of JVM heap) to a smaller size. I know your thinking - what make it less, but I want to make it bigger. Give less a try (sometimes less = more, bigger not = better) and monitor the situation. I like to use -Xmn switch, some sources say to use other method/s. Perhaps you could try java.args=-server -Xmx4096m -Xms4096m -Xmn172m etc. I better mention make a backup copy of jvm.config before applying changes. Having said that now you know how you can set the size to bigger if you want.
    I think the JVM is perhaps making some poor decisions with sizing the heap. With Eden growing to 1Gb then being evacuated not many objects are surviving and therefore not being promoted to Old Generation. This ultimately means the object will need to be loaded again latter to Eden rather than being referenced in the Old generation part of the heap. Adds up to poor performance.
    >Any other advice for performance improvements would be much appreciated.
    You are using Parallel garbage collector. Perhaps you could enable that to run multi-threaded reducing the time duration of the garbage collections, jvm args ...-XX:+UseParallelGC -XX:ParallelGCThreads=N etc where N = CPU cores (eg quad core = 4).
    HTH, Carl.

  • SystemManager and Garbage Collection

    Hi everyone, I have a question regarding the SystemManager and Garbage Collection. I have and application that loads in its assets via a swc created in Flash. In that swc I have different MovieClips that act as the different screens of my application each one being tied to its own custom class. For example one MovieClip is a login screen another is the main menu etc. These screens contain components, text fields and animations. The problem that I am having is when I move from one screen to the other the garbage collector is not cleaning up everything. There are still references to the MovieClips that have animations for example. So even though I remove the screen via removeChild and set the variable reference to that object to null it is not releasing the MovieClips. When I pull it up in the profiler it shows me that SystemManager is holding references to them. Also if I debug the applicaion and look inside the instance of the MovieClip I can see that the private property "listeners" has values, but I am not adding listeners. It appears that the SystemManager is adding listeners. Does anyone know how I can clear these listeners or force the SystemManager to release these items. Any ideas or help would be greatly appreciated. I am fairly new to dealing with memory management and garbage collection in Flex. I am using Flash CS4 to create the swc and Flash Builder 4 Beta with the 3.4 framework and Flash Player 10 to create the app. If you need me to clarify any of this please let me know. Again any help or ideas on where to go from here would be great!

    This chain says that the focusManager is referencing UserMenu.  Is there a default button or focusable objects in UserMenu and references from UserMenu to the objects in question?
    BTW, the CS4 fl.managers.FocusManager and any fl.. classes are incompatible with Flex, so make sure you're not using them in your MovieClips.
    Alex Harui
    Flex SDK Developer
    Adobe Systems Inc.
    Blog: http://blogs.adobe.com/aharui

  • Static class garbage collection

    Can garbage collector can garbage collect static classes ?.
    My doubt is that when you access a static class , that class is loaded through its class loader ( when first time that class is referenced ).
    So when did the garbage collector collects this static class ( assume that static class no longer referred ).
    Please do more information,
    What are the ways to prevent garbage collector for a particular class ( Assume that i m implementing a singleton for my java runtime)
    thanks and regards
    Renjith.

    Can garbage collector can garbage collect static classes ?. Static classes are nothing special in terms of class loading - they are only different in visibility for linking.
    Perhaps you mean static members of classes?
    My doubt is that when you access a static class ,
    that class is loaded through its class loader ( when
    first time that class is referenced ). Classes are always loaded through classloaders. Objects of those classes are allocated from the heap, and the object instances refer to the class object.
    Objects (either instances, or classes themselves) are garbage collected when they are no longer live (i.e. no live object refers to them). (This is a somewhat recursive definition, and sometimes, you can have cyclic dependencies that make garbage collection tricky, but the GC, while it has to be conservative for correctness, usually gets it right).
    So for a static member to be garbage-collected, the class has to be garbage-collected first. The class cannot be GC'ed until all references to it go away (this includes all dynamically allocated objects of that type, and the class loader that loaded that class).
    And yes, class loaders can go away, but only if they are created by your program. The system class loader (which is the default classloader you get if you don't create any class loaders of your own) never goes away, so any class loaded from CLASSPATH will never be unloaded.
    (As an example, servlet containers - e.g. Tomcat, Weblogic, etc.) allocate one or more classloaders for each webapp. When the webapp is un-deployed, the classloaders are "orphaned", and they, and any classes loaded by them (from the WEB-INF/lib and WEB-INF/classes directories) are unloaded and garbage-collected. (After all the dynamic objects of those classes are GC'ed, of course).
    >
    So when did the garbage collector collects this
    static class ( assume that static class no longer
    referred ).
    Please do more information,
    What are the ways to prevent garbage collector for a
    particular class ( Assume that i m implementing a
    singleton for my java runtime)
    thanks and regards
    Renjith.

  • No garbage collection data/detailed memory use data in Wily?

    Hi All,
    We are running some portals on AIX (1.4.2 SR12). We have installed the wily agent on the portals and the enterprise manager on our solman server. When looking in the introscope workstation the heap usage of the JVMs are shown as it should. However, the J2EE GC Overview 1/2 & 2/2 don't show any detailed data regarding garbage collection and memory usage (e.g. tenured; eden; etc...). At this moment we use IBM PMAT for memory analysis, but this is not real time. We would like to see memory details real time using Wily.
    Does anyone else also encounters this problem?
    Any suggestions?
    Thanks,
    Bart.

    Hello Amit
    Can you please open new thread for your question ?
    People won't check this thread to answer your question because the thread is marked "answered".
    Kind regards
    Tom

  • Why Garbage Collection take more time on JRockit?

    My company use <br>
    <b>BEA WebLogic 8.1.2<br>
    JRockit version 1.4.2<br>
    Window 2003 32bit<br>
    RAM 4 Gig<br>
    <br>
    -Xms = 1300<br>
    -Xmx = 1300<br></b>
    and running ejb application.<br>
    My problem is why JRockit take more time. How Can I solve this problem. Because my application will down again.
    <br>
    This is my infomation on JRockit :
    <br>
    Gc Algorithm: JRockit Garbage Collection System currently running strategy: Single generational, parallel mark, parallel sweep.
    <br>
    Total Garbage Collection Count: 10340
    <br>
    Last GC End: Wed May 10 13:55:37 ICT 2006
    <br>
    Last GC Start: Wed May 10 13:55:35 ICT 2006
    <br>
    <b>Total Garbage Collection Time: 2:53:13.1</b>
    <br>
    GC Handles Compaction: true
    <br>
    Concurrent: false
    <br>
    Generational: false
    <br>
    Incremental: false
    <br>
    Parallel: true
    <br>

    Hi,
    I will suggest you to check a few places where you can see the status
    1) SM37 job log (In source system if load is from R/3 or in BW if its a datamart load) (give request name) and it should give you the details about the request. If its active make sure that the job log is getting updated at frequent intervals.
    Also see if there is any 'sysfail' for any datapacket in SM37.
    2) SM66 get the job details (server name PID etc from SM37) and see in SM66 if the job is running or not. (In source system if load is from R/3 or in BW if its a datamart load). See if its accessing/updating some tables or is not doing anything at all.
    3) RSMO see what is available in details tab. It may be in update rules.
    4) ST22 check if any short dump has occured.(In source system if load is from R/3 or in BW if its a datamart load)
    5) SM58 and BD87 for pending tRFCs and IDOCS.
    Once you identify you can rectify the error.
    If all the records are in PSA you can pull it from the PSA to target. Else you may have to pull it again from source infoprovider.
    If its running and if you are able to see it active in SM66 you can wait for some time to let it finish. You can also try SM50 / SM51 to see what is happening in the system level like reading/inserting tables etc.
    If you feel its active and running you can verify by checking if the number of records has increased in the data tables.
    SM21 - System log can also be helpful.
    Also RSA7 will show LUWS which means more than one record.
    Thanks,
    JituK

  • Resources garbage collection, can be done this way ?

    The problem
    I would like to apply the same concept of garbage collection to system resources like Files, Database resulsets, Sockets etc...
    The reasons
    I am tired of looking around desperately into a program to identify memory leak that are instead resources leak. And this is getting worse while program size grows.
    How it could be done
    -- Let's have a resource manager class from where I get the wanted resource (I will write this class, fairly easy).
    -- Let's say that this manager class is a thread that runs in a scheduled way and this is decided by me (this is also something anybody can write).
    -- Let's say that when it runs it checks for all resources (objects) that it has given to the rest of the program if the reference count greater than one. If it is > 1 then the resource is still in use, else it can be deallocated (that just means calling close and then leaving the object to garbage collect).
    What I need
    A way to know in a reliable way how many objects are having a reference to a given object. Is there such a way ?
    Evangelism on..
    Please, if anybody at Sun is reading this, this IS a TOP issue. If you look around you will see more and more issues of leaking, they are resources leakage because it is NOT easy to ALWAYS close a resource.
    Someone may say "use the finally" of yes, try to think to use the finally to deallocate memory and you will immediatly understand the mess that will come.
    Garbage collection is a good idea let's have a way to apply it to resources.
    Thanks

    I have no problem, as it is, in making applications
    reliable.As usual the problems come in deciding how to do
    things.Yes.
    >
    Which is why mine don't. Since resources are usedin
    so few places it is easy to manage their usage.We are not talking on who has the biggest gun...Eh?
    >
    The sad thing is that the problem most of
    the time is NOT yours but of somebody else thatforgot
    to clean up after himself...Sounds more like a management problem than a code
    problem. If you are allowing programmers in your
    organization to write code which leaks resources oris
    so poorly designed that other users can notproperly
    dispose of resources then it is a managementproblem.
    Ok, let's drop it here.
    I hope you will never have to deal with code other
    that yours or written by your coworkers.
    I always deal with other people's code. And they with mine. Although I occassionally work on one person projects - perhaps 2 weeks every three years. the rest of my career has always involved multi-person projects and often (if not always) involve third party libraries.
    So I believe I have dealt with others code.
    in the applications that I work on.)There is java.lang.ref in a way it seems to dowhat
    I
    want....
    I don't believe so. Finalize() more closely fitswhat
    you might want to do. java.lang.ref is used in
    building caches of disposable entities. And it is
    most definitely only useable with memory.I have a funny sensation that whatever I write you say
    no...Not necessarily.
    Thanks for your help, if anybody wants to add
    something useful to
    what I am tryng to do they are welcome.I am trying to be useful.
    I am trying to point out that you are looking for a new feature in the language that just isn't very useful to most people. I was trying to point out why it wasn't useful to most people.
    Perhaps this might help.
    Look at it this way, go look at the bug database and look at the top vote getters for things that people want fixed. Then you might trying looking through the RFEs for something like you want. If it isn't there then add it. If enough people actually want it then it will be voted for. With enough votes it would have a better chance of being added.
    Of course that presumes it could be done in the first place. Based on my memory of past topics in the forums on reference counting I suspect that the answer is no. But you might want to read those.

  • GUI Garbage Collection

    Hi Everyone.
    This is very urgent. I need to perform a possible garbage collection of a heavy GUI stuff when it is not in use. Each of the GUI stuff is created from an action listener for the various menu items. I did try using WeakReference but its very hard to know that when the collection will take place.
    Here is the code snippet for the situation...
    //this is application's main frame class...
    public class MyApplication extends JFrame
    JMenuItem menu1, menu2;
    WeakReference ref_MyPanel;
    //earlier it was a strong reference of MyPanel over here
    public static void main(String [] args)
    //instantiating this class and showing that here ...
    //This is called from menu1's action listener..
    void showGUI()
    JFrame f = new JFrame();
    if(ref_MyPanel.get()!=null)
    f.getContentPane().add((MyPanel)ref_MyPanel.get());
    else
    MyPanel mp = new MyPanel();
    ref_MyPanel=new WeakReference(mp);
    f.getContentPane().add(mp);
    mp=null;//clearing the strong refernce
    f.show();
    //A GUI class which needs to be reclaimed when done
    class MyPanel extends JPanel
    double [] a;
    MyPanel1()
    a = new double [1000000]; //making the panel instance heavy
    What i want is to reclaim the memory occupied by MyPanel instance after its Frame being closed. I even tried calling the System.gc() from the MyPanel instance's parent frame's WindowListener -> windowClosed() but it didn't help. Actually this is suffering me a lot as there are several menu items and several GUIs are being instantiated similar to those of MyPanel as shown above. Do i need to change this design to achieve the objective?
    Can anyone help?

    We saw a significant memory improvement in our system when we used this
    utility. Try using this handy class to recursively remove each component
    For JFrames & JApplets I think it was
    ComponentCleaner.cleanComponent ( myFrame.getContentPane() );
    For Frames & Applets
    ComponentCleaner.cleanComponent ( myFrame );
    Also, for every addActionListener(), addComponentListener() etc call,
    you want a removeActionListener(), removeComponentListener() call.
    The listeners store references to the visual components if I remember rightly. So avoid anonymous listener classes, and have proper cleanup methods to remove the listeners.
    (code below)
    regards,
    Owen
    import java.awt.Container;
    import java.awt.Component;
    import javax.swing.RootPaneContainer;
    public class ComponentCleaner
        public static void cleanComponent(Component baseComponent)
            if (baseComponent == null) // recursion terminating clause
                return ;
            Container cont;
            Component[] childComponents;
            int numChildren;
            // clean up component containers
            if(baseComponent instanceof Container)
                // now clean up container instance variables
                if (baseComponent instanceof RootPaneContainer)
                   // Swing specialised container
                    cont = (Container)baseComponent;
                    numChildren = cont.getComponentCount();
                    childComponents = cont.getComponents();
                    for(int i = 0;i < numChildren;i++)
                        // remove each component from the current container
                        // each child component may be a container itself
                        cleanComponent(childComponents);
    ((RootPaneContainer)cont).getContentPane().remove(childComponents[i]);
    ((RootPaneContainer)cont).getContentPane().setLayout(null);
    else
    { // General Swing, and AWT, Containers
    cont = (Container)baseComponent;
    numChildren = cont.getComponentCount();
    childComponents = cont.getComponents();
    for(int i = 0;i < numChildren;i++)
    // remove each component from the current container
    // each child component may be a container itself
    cleanComponent(childComponents[i]);
    cont.remove(childComponents[i]);
    cont.setLayout(null);
    } // if component is also a container

  • Disabling RMI Explicit Garbage Collection

    I have an application that uses RMI. From different articles on the javasoft web site, I have read that RMI explicitly does a Full RMI every minute (default setting). This is undesirable, b/c these full GCs are causing some objects I need to use later to be garbage collected. From the site, the options are to:
    1) Disable Full GC
    2) Delay Full GC
    For point 1), what are the consequences of disabling explicit full GCing that RMI does? Documentation on the javasoft website only says that "this may also cause some objects to take much longer to be reclaimed" etc. To me, I would think that disabling the explicit Full GC is a bad idea for RMI applications (unless they are really short lived, but that is not my case). It would seem safer to go with 2) option to delay the Full GCs since it's not entirely clear what the consequences are of completey disabling explicit GCs, but this still causes objects I still need to use later to be garbage collected. The last option which I feel is not very elegant, would be to just set something to reference or use that object that is being gc'ed so when a Full GC is performed it doesn't get cleaned up. Does anyone have any experience with this or have any better suggestions?
    I am using Java 1.4.2 currently, but am also interested in learning what would be good for Java 1.2.X and 1.3.X as well.
    Thanks!
    These are the links that I have already visited or docs that I have already read on this topic:
    1) Java 2 Platform, Standard Edition v 1.4 Performance and Scalability Guide
    http://java.sun.com/j2se/1.4/performance.guide.html
    2) Frequently Asked Questions about Garbage Collection in the HotspotTM JavaTM Virtual Machine
    http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
    3) Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1
    http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/#11.1.3.15
    4) Garbage Collection for Remote Objects (1.4.2)
    http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-arch4.html

    Towards the end of my pot I wrote:
    The last option which I feel is not very elegant, would be to just set something to reference or use that object that is being gc'ed so when a Full GC is performed it doesn't get cleaned up. Does anyone have any experience with this or have any better suggestions?
    I realize that I can reference these objects, but I don't think that is really a great solution. This would mean deliberately referencing them (a hack at a solution in my view) when really it's the explicity GC running every minute (b/c of RMI) that is collecting them. If I turn the explicit GC off, my objects are not collected like this.
    My question was really does anyone have any better ideas or experience with RMI's explicit garbage collecting? I don't need to read a tutorial to tell me how to keep my objects alive by referencing them. Thanks.

  • Garbage collection – local variable

    I have a doubt in garbage collection.
    Please look int the below code.
    I hope that even if i didn't make myLocalVar = null; , i believe that garbage collection happens immediately,
    Please let me know am i right ?
    void method() {
      MyClass myLocalVar = null;
      try {
        myLocalVar = get_reference_to_object();
        //.. do more here ...
      } finally {
        if (myLocalVar != null) {
          myLocalVar.close(); // it is resource which we should close
        myLocalVar = null; // THIS IS THE LINE I AM TALKING ABOUT
    }

    JEisen wrote:
    es5f2000 wrote:
    I'm pretty sure that there's no guarantee that GC will run at termination time. That's what causes the issue with finalize(). It is theoretically possible to start a program, run it, and cleanly terminate it without getting a GC.True. I meant more that memory will be freed when the program terminates, not necessarily garbage collected. :)
    I just read about the finalize() gotcha -- never knew that. So is it possible for a program to exit without releasing I/O resources if they were being closed in finalize()?Yes and no.
    The basic answer is yes, however when the VM quits from an OS level the handles/locks/etc that were being used by the VM will, god willing, be released.
    A better example though is something like JDBC where you have remote resources waiting on a signal to be released. Having clean up code in finalize could well never be called and in that case the remote resources would be held on to.

  • Exorbitant Garbage Collection Times

    Once a day, at around 4-4:30am, our application experiences a single Full GC with taking an exorbitant amount of time. A Full GC kicks in and pauses all threads for 5 to 30 minutes. Full GC's regularly occur at other times and complete in 5-20 seconds. Anyone seen this or any have any ideas about this?
    Example of normal GC that occurs frequently throughout the day:
    [Full GC[Unloading class $Proxy136]
    4632722K->1616289K(6141952K), 14.9400110 secs]
    Example of ridiculously long GC that occurs daily at 4-4:30am:
    [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor455]
    5456231K->2017269K(6141952K), 492.0402160 secs]
    Here's our VM params:
    -server -XX:-OmitStackTraceInFastThrow -Xincgc -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:MaxGCPauseMillis=20000 -XX:+DisableExplicitGC -XX:NewSize=1500m -XX:SurvivorRatio=18 -verbose:gc
    -Xms6000M -Xmx6000M
    We're running Java 1.6 on Linux, Redhat 3.

    Just experienced a 498 second (yikes!) garbage collection pause. The entry from the log is below (we added -XX:+PrintGCTimeStamps -XX:+PrintGCDetails and removed -verbose:gc). I will also send the entire log to the email address you have provided.
    Note that we actually reduced our Xmx to 4000M (from 6000M) despite this machine having 8gig physical ram in the hopes that this would prevent any paging, and it seems to have drastically improved the situation - these exorbitant pauses now occur only very seldomly.
    This is the full command we're justing to start the JBoss JVM:
    /proj/bo/apps/jdk/production/bin/java -Dprogram.name=run.sh -server -XX:-OmitSta
    ckTraceInFastThrow -Xincgc -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:MaxGCPauseMillis=20000 -XX:+DisableExplicitGC
    -XX:NewSize=1500m -XX:SurvivorRatio=18 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Djava.endorsed.dirs=/var/local/jboss/jboss-c
    urrent/lib/endorsed -Dsystem.state=production -Dcom.hb.common.api.util.Environment.app.name=Hermes -Djboss.partition.name=as20.
    nyc.hcmny.com -Dorg.jboss.security.SecurityAssociation.ThreadLocal=true -Doracle.net.tns_admin=/var/opt/oracle/etc -Djnp.discov
    eryPort=1103 -classpath /var/local/jboss/jboss-current/bin/run.jar:/proj/bo/apps/jdk/production/lib/tools.jar -Xms4000M -Xmx400
    0M -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8134 -Dcom.sun.management.jmxremote.authenticate=true -Dc
    om.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.password.file=/proj/bo/jmxremote.password org.jboss.Main -
    cdefault
    This is the exact JRE we're using:
    java version "1.6.0"
    Java(TM) SE Runtime Environment (build 1.6.0-b105)
    Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)
    Here's the 498 second GC pause:
    103999.802: [GC 103999.802: [ParNew (promotion failed): 1459200K->1459200K(1459200K), 478.7897900 secs]104478.592: [CMS104483.552: [CMS-concurrent-mark: 5.170/491.280 secs]
    (concurrent mode failure)[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor605]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor866]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor870]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor887]
    [Unloading class sun.reflect.GeneratedMethodAccessor267]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor864]
    [Unloading class sun.reflect.GeneratedConstructorAccessor148]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor861]
    [Unloading class sun.reflect.GeneratedMethodAccessor268]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor606]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor862]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor886]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor706]
    [Unloading class sun.reflect.GeneratedConstructorAccessor145]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor865]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor350]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor860]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor868]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor863]
    [Unloading class sun.reflect.GeneratedConstructorAccessor147]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor867]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor869]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor185]
    [Unloading class sun.reflect.GeneratedConstructorAccessor125]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor871]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor707]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor708]
    : 2517456K->2073715K(2560000K), 19.7399910 secs] 3927185K->2073715K(4019200K) icms_dc=5 , 498.5297810 secs]
         at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
         at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
         at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1838)
         at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1747)
         at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:226)
    21:37:07,931 WARN [TransactionImpl] Transaction TransactionImpl:XidImpl[FormatId=257, GlobalId=as20.nyc.hcmny.com/163214, BranchQual=, localId=163214] timed out. status=STATUS_ACTIVE
    2007-09-12 21:37:08

  • Runtime.getRuntime().exec() and Garbage Collection

    I am programming a piece of software in both Java and C that has some strict real time requirements. Garbage collection, which pauses all threads in Java, sometimes causes loss of incoming data. In order to get around this, I am thinking to start another process using Runtime.getRuntime().exec("c_program") and using interprocess controls (in a UNIX environment) to retrieve data from the new process.
    My only worry is that the Process created by the above call would be a child process of whatever JVM thread created it, (as far as I understand, the JVM implementation in Unix uses multiple processes) and would also be paused when garbage collection occurs. Does anyone know the implementation of the exec functionality and the JVM well enough to say that this will or will not happen?
    Thanks in advance,
    Benjamin

    You're going to create a whole new process? I don't
    know what a "child process" means, but Runtime.exec()
    gets the operating system to produce an entirely new
    process, outside the JVM. However if it produces
    output on stdout or stderr, you're going to have
    threads in your JVM that read that output, otherwise
    that process will hang.
    Why is your idea better than just calling the C
    program via JNI?Thank you both for your replies. My plan was to create a whole new process, yes. In UNIX, a process C is created by another process P using fork() or the exec() family. Process P is then the parent of process C, and process C is the child of Process P. P has an amount of control over C since it can send various signals to pause, kill, etc to C.
    My concern was that the JVM implementation would use these signals to implement the pause of all threads before garbage collecting. If it did, it may also pause the Process that it spawned from the Runtime.exec() call. Pausing my C program in this manner would cause the loss of data I was trying to avoid in the first place.
    My plan for the new process was not to produce anything on stdout or stderr, but to pass data back to the JVM using ipc (interprocess communication) resources of UNIX. I would have to use the JNI to access these resources.
    The whole reason for wanting to do this is to avoid the pause during garbage collection that all Java Threads experience. If I were just to call the C program through the JNI with a normal Java Thread as I think you were suggesting, this Java Thread would still be paused during garbage collection.
    To the second reply about RTSJ, I had heard about this but couldn't find info about it! Thanks for the link. I'm checking it out at the moment. The java runtime must be considerably different for the specifications I see that they guarantee.
    Again, thanks for the replies,
    Benjamin

  • Applescript: force garbage collection?

    Hello
    I am trying to call applescript functions (from my cocoa application - using NSAppleScript's -executeAndReturnError), to automate some operations in Microsoft Word.
    The problem is that after every Applescript call, the Word operates slower and slower (and i guess finally it won't respond at all). I am calling operations, like "set myvar to all words of current document whose [some conditional]" or "set myvar to all fields of current document whose [some conditional]" (which are memory consuming - on each call Word enumerates all the words of a long document, searches there some matches, etc), and i think that after each call of NSAppleScript's -executeAndReturnError, Word doesn't clean its previous "results", which slows it down with every next call. I wanted to try to do an explicit call of Applescript's garbage collector after each -executeAndReturnError from my Cocoa app, maybe that could eliminate the problem i have.
    But i didn't find any info on how to do that. Java, ActionScript - both have System.gc() functions (that launch Garbage collection if it's needed right here and right now). If theres no way to force garbage collecting in AppleScript, maybe someone knows "implicit ways", when AppleScript engine calls it? Like the next iteration of a loop, or some other conditions? Or some timespan, after passing which the GC is called?
    What could cause that slowness of Mac:Word? Is it a mistake of Microsoft, or am i forgetting to do something? If someone could advice readings about how applications usually implement Applescript interface "from the inside" (and who is responsible for cleaning the results of each call), i'd be very thankful.
    Thanks for any advice!
    George

    If you really want to see the results you should also run the finalizer
    thread on the newly garbage collected objects. It might take up to 2 GC
    cycles for the memory to be actually free for new allocation at least on
    the Sun JVMs. Maybe the new types of garbage collectors do it better or
    more optimized but anyway, the GC would first mark the objects and only
    then the finalizer will run to call the finalize method. Then next GC
    will free the memory of the finalized objects.
    HTH,
    Dejan
    Dinesh wrote:
    Hi Slava Imeshev,
    Thanks for immediate response. I agree JVM will do GC at specific interval. But,
    I have found that , there is some difference in both of them. If you invoke "Force
    Garbage Collection" explicitly, the graph will show the heap memory usage to baseline.
    Where in, if you perform System.gc(). It won't make much difference.
    Thus why, I want to know what is the code behind the "Force Garbage Collection"
    button.
    Thanks,
    -Dinesh.
    "Slava Imeshev" <[email protected]> wrote:
    "Dinesh" <[email protected]> wrote in message news:406a8df4$[email protected]..
    How can i schedule "Force Garbage Collection" to be done at every
    week or daily?.
    Can i automate this process instead of manually invoking the button?
    GC is already done by JVM automatically.
    Why would you want to "schedule" it?
    Regards,
    Slava Imeshev

  • How to encourage jvm to garbage collect?

    Hello,
    I am working with an application that would benefit from more frequent garbage collection. It is running on a hefty machine, with multiple processors and more than 4 gigs of memory available for the JVM. Right now, we are setting the max heap size to 3 gigs.
    The problem is that objects are accumulating, but are not being collected. During a particular operation that I am profiling, over 1 gig of objects are created, but are never collected. If I do a manual garbage collect (using jprofiler), they are all collected. There is no good way to load these objects in another way, or to create fewer objects.
    I have spent a few days playing with -XX:MaxNewSize, -XX:NewSize, -XX:MaxHeapFreeRatio, -XX:TargetSurvivorRatio, and even -XX:+UseParNewGC. Unfortunately, I am unable to encourage the JVM to collect these objects automatically.
    Are there any tricks that I am missing? Does anyone know any good way to encourage the JVM to collect garbage after a certain threshhold in the new generation?
    Thanks,
    --Jeff                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    You can try this!
    How do I set the JVM's heap size?
    On machines with limited memory (less than 384MB), it is recommended that you set the initial heap size lower than the default. Open the configuration file etc/netbeans.confin a text editor and modify the options in netbeans_default_optionssetting. Decrease the option -J-Xmx128mto -J-Xmx96m and the option -J-XX:MaxPermSize=96mto -J-XX:MaxPermSize=64m. Save the file and restart the IDE.
    Bear in mind that UI responsiveness may be affected when the heap utilization gets close to its limit. Should you encounter an OutOfMemoryError, you need to increase Xmx or XX:MaxPermSize back to the default, or even higher.
    Similarly when running on a machine with more memory it might be useful to increase the maximum size of the heap, especially when working with larger projects. Use the page linked below to get more details on this topic.
    Applies to: NetBeans 4.x, 5.0
    Platforms: All

Maybe you are looking for