Garbage Collection is not destruction?

Garbage Collection is not destruction?
This is one of the point from Thinking In Java 4th edition Chapter 5.Can someone please explain me this point.Does that mean that Garbage Collection does not destroy objects.If yes,then what is it role?
And also please explain something about finalize().I tried to read it but couldn't understand.
Thanks for your help.

personal opinion really. I do call garbage collection destruction, the memory occupied by the objects in question is reclaimed. It is a discussion point however as it is from the perspective of the JVM; from the perspective of the application the object is "destroyed" as soon as you cut all references to it.
What to explain about finalize()? It is invoked right before an object is garbage collected, possibly allowing you to do some last minute clean up jobs, like letting go of resource handles and such. The general rule about it is that in 99.99% of the cases you need not touch it. If you have a design where you need it, it is best to assume the design is wrong and you need to change it. For example in the case of closing resources, it is better to have a close() method that needs to be invoked manually.
If you do use it, you better be really sure that you know what you are doing as you may cause performance problems or even hard to trace unexpected behavior.

Similar Messages

  • Full garbage collection issue, not releasing/flagging memory

    I have the following problem running on a multi-cpu windows server with Java 1.4.2_05 using WebLogic 8.1:
    During a lifecyle of the web application (under load, but not to heavy) memory usage seems ok and garbage collection is called regularly. Suddenly, the used heap starts to rize very fast and after a while, even a full garbage collection cylce, does not release any memory anymore.
    I am sure that, from our coding, we release memory ok, and normally we should only use about 5 to 10 mb for each user max (with0 normal defnew garbage collections).
    I tried changing the garbage collection parameters, but this does not solve the problem. Best scenario was with the concurrent collector and I got this output at +/- the end:
    [GC 100202K->93511K(115628K), 0.0091472 secs]
    [GC 148480K->139612K(163808K), 0.0225914 secs]
    [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor289]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor290]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor273]
    153750K->133006K(164064K), 1.2434402 secs]
    [GC 148939K->137948K(203264K), 0.0223085 secs]
    [GC 188789K->177116K(203264K), 0.0180729 secs]
    [Full GC[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor312]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor322]
    [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor309]
    189788K->170264K(203264K), 1.1851945 secs]
    [Full GC 203228K->203227K(203264K), 1.2876122 secs]
    [Full GC 203263K->203233K(203264K), 1.3354548 secs]
    [Full GC 203263K->203258K(203264K), 1.2873518 secs]
    <Jan 17, 2007 9:40:40 AM EST> <Error> <HTTP> <BEA-101017> <[ServletContext(id=33114655,name=console,context-path=/console)] Root cause of ServletException.
    java.lang.OutOfMemoryError
    >
    [Full GC 203263K->203233K(203264K), 1.2814516 secs]
    [Full GC 203233K->203231K(203264K), 1.6029044 secs]
    [Full GC 203263K->203242K(203264K), 1.3081352 secs]
    <Jan 17, 2007 9:41:51 AM EST> <Emergency> <WebLogicServer> <BEA-000210> <The WebLogic Server is no longer listening for connections.>
    [Full GC 203263K->203247K(203264K), 1.3161194 secs]
    [Full GC 203263K->203249K(203264K), 1.2954988 secs]
    [Full GC 203263K->203247K(203264K), 1.6423404 secs]
    <Jan 17, 2007 9:41:57 AM EST> <Alert> <WebLogicServer> <BEA-000218> <Server shutdown has been requested by <WLS Kernel>>
    [Full GC 203263K->203250K(203264K), 1.3161025 secs]
    Another strange item is: I maximized the amount of memory it uses to 512m with the Xmx parameter, I am almost sure that that one is used, but it never gets higher than 203M? Does anyone know why this is?
    Another strange item: the monitoring in the weblogic code indicates 32MB of usage (relative memory usage seems to be ok, but the quanity indication is just plain wrong) with 15 threads running.
    This problem does not exist when using JBoss 4.0.2 or 4.0.3 (standard j2ee settings).
    If anyone has an idea or can help me, I would appreciate it very very much. :)

    Hi ,
    Is this issue resolved ?
    we are facing same problem.
    1. We have checked the CPU and memory utilization everything is normal
    2. GC logs showing FULL GC calls continuously
    3. After restart the resin server system is working normally.
    Environment detail
    Resin ./resin-pro-3.0.18 on suse Linux
    Java JDK1.4.2_08
    Please suggest

  • Garbage Collection is Not working

    I Installed J2dk1.4 in my System.it's garbage Collector is not working,It does'nt free the memory in case of Frames and Applets.I use many methods to explicitly free the memory, Like :
    ====================
    System.exit(0);
    System.gc();
    ====================
    but it does'nt work can any body give me the solution?
    Email : [email protected]

    How are you determining that it doesn't free memory?
    If you're expecting Task Manager to show the VM using less memory, that won't happen. GC frees memory internally, so it can use that memory for other objects. It doesn't return it to the OS.
    Also, calling gc() will not necessarily force the GC to run. Unless you're using a profiler, or getting OutOfMemoryError, you can't say for certain that the VM is not releasing memory.
    Also, even if it's not releasing it, it doesn't mean it's a problem. It's guaranteed to release it when it needs it, but it may or may not release it sooner.
    Finally, System.exit may not do anything in an applet, for security reasons.
    What is your actual problem?

  • All Tweens randomly halting (Not Garbage Collection)

    I am developing a game with some AS3 tweens. I have encountered the problem of garbage collection affecting tweens before so I have all my tweens referenced at the class level now to ensure that isn't a problem. However, randomly all the current tweens in my game will stop. Other, non-tweened, frame by frame animations continue. It's just like the garbage collection problem but the tweens shouldn't be being collected...
    The code I am using for tweens:
    Var declaration at the top of the class:
    private var gateTween:Tween;
    This code in a function:
    gateTween = new Tween(currentGate, "x", None.easeOut, 800, 380, 1.5, true);
    gateTween.addEventListener(TweenEvent.MOTION_FINISH, horseJump);
    Any ideas would be appriciated.

    I have Swing based java project. Im setting all the
    references to null as and when i dont need them, and
    then im calling System.gc() also.
    However it seems the memory is not being released,
    when i check in the task manager, memory usage does
    not reduce. It seems garbage collection is not
    happening.Actually I have a small class - where in I try to do this:-
    public class TestDebug extends Object{
    /** Creates a new instance of TestDebug */
    public TestDebug() {
    * @param args the command line arguments
    public static void main(String[] args) {
    System.out.println("Trying to debug this");
    TestDebug testDebug = new TestDebug();
    testDebug.finalize();
    System.out.println("Lasting print");
    public void finalize(){
    System.out.println("Finalize called");
    System.gc();
    System.out.println("Finalize finished");
    But it is also true that you should never try to force it - It has its own way to do it.
    For Example try to execute a big code(so that you can find JVM doing the GC) as "java -verbose:gc class-name"
    You will find at some points during the execution process - that the JVM actually runs the GC on its own- but when not that is not defined.It is a low priority thread running under JVM.

  • When will wls try to garbage collect ?

    The docs for the option "Low memory GC threshold" say that this is the "Threshold
    level at which WLS will try to garbage collect once the granularity report has
    been met".
    My question is: When is this condition met ? If at least once there has been a
    granularity report in the log ? Or if the server has been set to Warning state
    The problem Im trying to address is that my "Low memory GC threshold" is set to
    20% and my server has reached only 1% free memory and garbage collection did not
    run, I had to force it via console.
    Thanks in advance, Giselle

    I am wonder when the WLS activate or passivate session and how can I          control it?
              > From documents, sessionWillPassivate in HttpSessionActivationListener will
              be
              > executed when a session is about to passivate on one server (ie. WLS
              instance)
              > and the sessionDidActivate method when the same session has been activated
              on
              > a second server.
              >
              > But I have monitor the behavior for a long time by setting
              PersistentStoreType
              > to file, memory, replicated. sessionDidActivate and sessionWillPassivate
              will
              > never executed. I expected it will passivate and activate when session is
              replicated
              > between servers or persist in files. Any ideas?
              What version of WL? the interface you describe was new in Servlet 2.3, so it
              may not be implemented until 6.1 or even 7.x.
              Peace,
              Cameron Purdy
              Tangosol, Inc.
              http://www.tangosol.com/coherence.jsp
              Tangosol Coherence: Clustered Replicated Cache for Weblogic
              "Karen Law" <[email protected]> wrote in message
              news:3ec86188$[email protected]..
              >
              

  • Memory leak in java / forcing garbage collection for unused resource?

    Is there any possibility in big programs if not designed properly for leakage of memory?
    If say i forget to force garbage collection of unused resouces what will happen?
    Even if i am forcing garbage collection how much assurity can be given to do so?
    I need answers w.r.t typical programming examples if someone can provide i will be happy.
    Or any useful link.
    Thanks
    Vijendra

    Memory leaks are usually much related with C/C++ programming since in that language you have direct access to memory using pointers.
    Now, in Java you do not have access to pointers, however you could still tie up your objects in a way that the garbage collection can not remove them.
    Basically, the grabage collection will search all the object implementation, and see if they are referenced or not. If not it will free that memory. However if you, somehow in you code allow a reference to your object then the garbage collection will not displose of that object.
    An example I can think of is when developing web applications. For example storing objects in the session will mean that you will have a reference to the object from the session, therefore the garbage collection will not free up the meomry taken by those objects untill the session has expired.
    That is how I know it... at least that is how they tought it to me!
    regards,
    sim085

  • Nested object reference after garbage collection

    I have a question about how GC works.
    Assume I have a Class A which has a reference to class B inside it. I create a object of class B and assign to member variable of class A.
    Now when obja is no longer needed, I set it null. And when GC runs, the object will be removed from memory. But should I also need to explicitly set objb to null. If i don't set it, will it also get garbage collected when obja is being removed from memory?
    public class ClassA {
    private ClassB objB = new ClassB();
    private static void main(String args[]) {
    ClassA obja = new ClassA();
    obja = null;
    }

    801625 wrote:
    But should I also need to explicitly set objb to null.No.
    If i don't set it, will it also get garbage collected when obja is being removed from memory?If there are no other references outside of classA to the object referenced by objB (in your case an instance of ClassB) then it will be garbage collected.
    Note - the only time one needs to set a reference to null is if one wants the object it references to be eligible for GC before the reference goes out of scope. There is a slight complication to this - depending on the JVM implementation, if a reference is defined in a block internal to a method then even though it goes out of scope when execution goes out of the block anything it references may not be eligible for GC until the method exits.

  • URL class is not being garbage collected

    I have created two instances of the URL class to specify a file location for each image. I use com.symantec.itools.javax.swing.icons.ImageIcon class to display images specified by each URL instance as icons inside a button. The setImageLocation method(URL location) of the ImageIcon class sets the location to be displayed by this icon. The following is the code snippets used to create the ImageIcon instances:
    private URL greenIconURL;
    private URL redIconURL;
    com.symantec.itools.javax.swing.icons.ImageIcon green_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
    com.symantec.itools.javax.swing.icons.ImageIcon red_icon = new com.symantec.itools.javax.swing.icons.ImageIcon();
    try
    greenIconURL = new java.net.URL
    ("file:./images/greenline.gif");
    green_icon.setImageLocation(greenIconURL);
    catch (java.net.MalformedURLException error) { }
    try
    redIconURL = new java.net.URL
    ("file:./images/redline.gif");
    red_icon.setImageLocation(redIconURL);
    catch (java.net.MalformedURLException error) { }
    I am using JProbe 5.0.1 Memory to determine the loitering objects when I remove the button from the JInternalFrame. I am using Java 1.2.2_08 version. The JProbe Memory Leak Doctor indicates that each URL instance has a reference to an entry in a HashMap table. The reference graph from the root set has a reference to SoftCache to HashMap to HashMap$Entry. To make this URL instance eligible for garbage collection, JProbe Memory Leak Doctor indicates I must remove the entry from the HashMap. How do I get access to this HashMap to remove the entry? If this is a problem with the version of the JDK, please let me know. Thank you in advance for your assistance.

    <root>Statics
    -->sun.misc.SoftCache->java.util.HashMap->java.util.Has
    Map$Entry[]->java.util.HashMap$Entry->java.net.URL
    I do not an instance of HashMap in my class.
    Therefore, the HashMap is either created by URLclass
    or the
    com.symantec.itools.javax.swing.icons.ImageIcon
    class.SoftCache seems to have a normal HashMap inside
    it/* Hash table mapping keys to ValueCells */
    private Map hash;but if that is the HashMap in JProbe
    information then the URL would have to be a key in
    the map - otherwise there'd be another object in the
    chain of class SoftCache.ValueCell
    are you certain that the java.net.URL's in that
    hashmap are your ones?
    out of curiosity - are you certain that the URL's are
    the/a problem (are you getting an OutOfMemoryError?)
    asjfThe button that contains the URL's is the only one on the JInternalFrame. The JProbe Memory Debugger displays the java.net package name, the URL class name, the count (2), and the Count Change (+2). When I remove the button from the JInternalFrame, the aforementioned numbers on the Instance Summary remain the same. The snapshot of the Java Heap reveals that the two instances of the URL class are still there. The Memory Leak Doctor shows the reference graph from the root set:
    <root>Statics->SoftCache->HashMap->HashMap$Entry[]->HashMap$Entry->URL
    When I right click on the arrow between HashMap$Entry[] and HashMap$Entry to remove the reference, I receive the message: "Congratulations this object can be garbage collected..." It appears like private instance of Map in SoftCache is holding a strong reference.
    I am not getting an OutOfMemoryError exception.

  • Garbage Collection not releasing memory properly

    Hello, In my web application memory is not releasing properly, after some point of time application throw out of memory error, we are using tomcat5, jdk5, my heap size is half of the RAM.Garbage Collection not releasing memory properly.

    sabre150 wrote:
    punter wrote:
    georgemc wrote:
    Yep. Couldn't be a problem with your code, it must be that garbage collection doesn't work and nobody else noticed. Raise a bug with Sun.Are you serious ?You need to replace your sarcasm detector.I have blowed my sarcasm meter and limping in the blindness !!!! :(

  • This byte array is not garbage collected?

    imageBytes[] does not seem to ever be garbage collected. I've pinpointed a SINGLE LINE that, when commented out, will prevent the memory leak. What could possibly be wrong with this line?
    Running this code results in a "OutOfMemoryError: Java heap space" after roughly a minute on my machine. I'm using JRE version 1.5.0_08.
    import javax.imageio.ImageIO;
    import java.awt.*;
    import java.awt.image.*;
    import java.io.*;
    // creates images to send to ImageConsumer
    public class ImageProducer {
         static BufferedImage bufferedImage;
         static Robot robo;
         static byte[] imageBytes;
         public static void main(String args[]) {
              try {
                   robo = new Robot();
              } catch(Exception e) {
                   e.printStackTrace();
              PipedOutputStream pos = new PipedOutputStream();
              new ImageConsumer(pos).start();
              bufferedImage = robo.createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize()));
              try {
                   ObjectOutputStream oostream = new ObjectOutputStream(pos);
                   ByteArrayOutputStream baos = new ByteArrayOutputStream();
                   ImageIO.write(bufferedImage, "JPG", baos);
                   baos.flush();
                   imageBytes = baos.toByteArray();
                   while (true) {
                        ImageIO.write(bufferedImage, "JPG", baos);
                        baos.flush();
                        // THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
                        // If you comment the following line out, there will be no
                        // memory leak. Why?  I ask that you help me solve this.
                        imageBytes = baos.toByteArray();
                        baos.reset();
                        oostream.writeObject(imageBytes);
                        pos.flush();
              } catch (Exception e) {
                   e.printStackTrace();
    // This thread reads the image data into bImg
    class ImageConsumer extends Thread {
         BufferedImage bImg;
         PipedInputStream pis;
         ImageConsumer(PipedOutputStream pos) {
              try {
                   pis = new PipedInputStream(pos);
              } catch (IOException e) { e.printStackTrace();}
         public void run() {
              try {
                   ObjectInputStream oinstream = new ObjectInputStream(pis);
                   while (true) {
                        byte[] imageBytes = (byte[])oinstream.readObject();
                        ByteArrayInputStream bais = new ByteArrayInputStream(imageBytes);
                        bImg = ImageIO.read(bais);
              } catch (Exception e) {e.printStackTrace();}
    }

    while (true) {
         ImageIO.write(bufferedImage, "JPG", baos);
         baos.flush();
         // THIS SEEMS TO BE WHERE THE MEMORY LEAK OCCURS: imageBytes
         // If you comment the following line out, there will be no
         // memory leak. Why? I ask that you help me solve this.
         imageBytes = baos.toByteArray();
         baos.reset();
         oostream.writeObject(imageBytes);
         pos.flush();
    }I have only briefly gone through the code, but why are you flushing it right before calling that line. Won't the byte array returned always be empty right after flushing the stream?

  • WLS not garbage collecting enough?

    WLS 5.1 SP5
    SunOS 5.6 (2.6)
    JDK 1.2.2_005a (with the JVMARGS directive set as per BEA's docs. The
    JVMARGS directive solved the SIGBUS 10 for us when requesting the
    AdminMain servlet)
    We tried some stress testing of our web app by running about 100 to 200
    virtual clients requesting the same URL (servlet that forwards to a
    JSP). These virtual clients are actually Java threads running
    simultaneously.
    After each test, we notice that, via WL console, the heap usage of WL
    increased. However, after leaving WL server by itself (no HTTP requests
    coming to it) for a long time (say 30 minutes to 1 hour), we noticed
    that the heap usage has not gone down, except for about 1%. As soon as
    we explicitly tell WLS to garbage collect via the WL console, then the
    heap usage goes down ... sometimes even as low as just 10% when we tell
    it to gc again just after a gc a few seconds earlier.
    Is this proper behaviour by WLS? ... or does this have something to do
    with the JVMARGS directive? Why doesn't it gc even after a long time?
    Thanks in advance,
    John Salvo
    Homepage: http://homepages.tig.com.au/~jmsalvo/

    There are a number of problems with memory usage and garbage collection. Going to WLS 5.1 will fix
    some of them. You should also consider having your application call System.runFinalization(); and
    System.gc() from time to time.
    Mike
    "Jim Zhou" <[email protected]> wrote:
    I see the same behavior in my stress test/pre-production run. I think it's
    normal behavior. The GC will kick in when the heap size gets 100%, you might
    see a pause in your WLS because all threads will stop for the GC ( you
    should see CPU really busy when GC is in ). JDK 1.2 should have better GC
    algorithm than JDK 1.1. Usually for people still using JDK1.1.x, tuning the
    heap size for tolerable GC pause is a pain., the tuning guide want you to
    run multiple WLS instances in a box to stagger the effects of GC pause. If
    you use JDK 1.2, you probably set your heap size comparable to your box's
    memory.
    In one of my stress test, I set heap size to 256m, I see on my console the
    heap gets full every 30 seconds, and it take 1 or 2 seconds to GC. But if
    your heap is 2G, it might take longer.
    WLS 4.51 SP11
    Solaris 2.6
    JDK 1.2.2_06.
    Regards,
    Jim Zhou.
    Jesus M. Salvo Jr. <[email protected]> wrote in message
    news:[email protected]...
    WLS 5.1 SP5
    SunOS 5.6 (2.6)
    JDK 1.2.2_005a (with the JVMARGS directive set as per BEA's docs. The
    JVMARGS directive solved the SIGBUS 10 for us when requesting the
    AdminMain servlet)
    We tried some stress testing of our web app by running about 100 to 200
    virtual clients requesting the same URL (servlet that forwards to a
    JSP). These virtual clients are actually Java threads running
    simultaneously.
    After each test, we notice that, via WL console, the heap usage of WL
    increased. However, after leaving WL server by itself (no HTTP requests
    coming to it) for a long time (say 30 minutes to 1 hour), we noticed
    that the heap usage has not gone down, except for about 1%. As soon as
    we explicitly tell WLS to garbage collect via the WL console, then the
    heap usage goes down ... sometimes even as low as just 10% when we tell
    it to gc again just after a gc a few seconds earlier.
    Is this proper behaviour by WLS? ... or does this have something to do
    with the JVMARGS directive? Why doesn't it gc even after a long time?
    Thanks in advance,
    John Salvo
    Homepage: http://homepages.tig.com.au/~jmsalvo/

  • Oracle JVM Garbage Collection not executing

    I am experiencing a problem with garbage collection when running a java stored procedure in an 9.2.0.3.0 Oracle database running on a Windows 2k computer.
    I have created a simple java class that represents a tree structure. Each instance of the class has a reference to it's parent and a Vecotor of all it's children. Each instance also has a Vector to hold name value pairs. I ran a program that creates 30 instances with 50 children each for a total of 1500 instances. Each instance has 30 properties(name value pairs).
    By using the debugger in JDeveloper and breakpoints I can watch the javaw.exe process's use of RAM.
    Start up: 6,788mb
    After creation of 1500 instances: 17,720
    After releasing all objects and calling System.gc(): 7,156
    I deploy the package to my Oracle database and perform the exact same routine using breakpoints and test procedures in plsql Developer. Using the breakpoints and watching the oracle.exe process's use of RAM I see:
    Start up: 81,116mb
    After creation of 1500 instances: 94,952
    After releasing all objects and calling System.gc(): 95,036
    When run in Oracle the resources are not released. Is there somthing special that needs to be called to get the garbage collector to do it's job when running in an Oracle database?
    Execution Instructions and source:
    run app.main from jdeveloper and app.main2 as a plsql stored procedure. I have included my test procedure at the end and the plsql stored procedure package declarations. I used debuggers and breakpoints to watch the process, there is probably a way to do this by outputting the current memory being used by I didn't know how. If you use debuggers and breakpoints then when running in JDeveloper put your breakpoints on the 3 assignments of breakpointVar in SimpleClass.main(...). When running the stored procedure test block put them on the 3 assignments of breakpoint_var in there.
    package mypackage2;
    public class app {
    private static SimpleClass topObject;
    public static void main(String[] args) {
    int breakpointVar;
    breakpointVar = 0;
    main2(30, 50);
    breakpointVar = 1;
    release();
    breakpointVar = 2;
    public static void main2(int numParents, int numChildren){
    SimpleClass temp;
    SimpleClass child;
    topObject = new SimpleClass();
    for(int i = 0; i < numParents; i ++){
    temp = new SimpleClass();
    addProperties(temp, 30);
    topObject.addChild(temp);
    for(int j = 0; j < numChildren; j++){
    child = new SimpleClass();
    addProperties(child, 30);
    temp.addChild(child);
    public static void release(){
    topObject.releaseAllDecendents();
    topObject.release();
    System.gc();
    private static void addProperties(SimpleClass toAddTo, int numProps){
    cimxProperty toAdd;
    for(int i = 0; i < numProps; i ++){
    toAdd = new cimxProperty("prop "+i,"value "+i);
    toAddTo.addProperty(toAdd);
    package mypackage2;
    import java.util.Vector;
    public class SimpleClass {
    private Vector _children;
    private Vector _props;
    private SimpleClass _parent;
    public SimpleClass() {
    _children = new Vector(10, 5);
    _props = new Vector(10, 5);
    _parent = null;
    public void addChild(SimpleClass toAdd) {
    toAdd._parent = this;
    _children.add(toAdd);
    public SimpleClass getChild(int index){
    return (SimpleClass)_children.get(index);
    public void addProperty(cimxProperty toAdd){
    _props.add(toAdd);
    public cimxProperty getProperty(int index) {
    return (cimxProperty)_props.get(index);
    public void releaseAllDecendents()
    SimpleClass temp;
    //remove all references to the the parent object from the children.
    for(int i = 0; i < _children.size(); i ++)
    temp = (SimpleClass)this._children.get(i);
    temp.releaseAllDecendents();
    temp._parent = null;
    temp._props.clear();
    temp._children.clear();
    temp = null;
    this._children.clear();
    public void release() {
    this._parent = null;
    this._children.clear();
    this._props.clear();
    package mypackage2;
    public class cimxProperty
    private static String _dateFormat = "MM/DD/YYYY HH:MI:SS";
    private String name;
    private String value;
    private String dataType;
    public cimxProperty()
    name = "";
    value = "";
    dataType = "";
    public cimxProperty(String Name, String Value)
    name = Name;
    value = Value;
    dataType = "UNKNOWN";
    public cimxProperty(String Name, String Value, String DataType)
    name = Name;
    value = Value;
    dataType = DataType;
    public String toString()
    return name + "["+dataType + "]: " + value;
    public void setName(String name)
    this.name = name;
    public String getName()
    return name;
    public void setValue(String value)
    this.value = value;
    public String getValue()
    return value;
    public void setDataType(String DataType)
    this.dataType = DataType;
    public String getDataType()
    return dataType;
    CREATE OR REPLACE PACKAGE JAVA_MEMORY_TEST AUTHID CURRENT_USER AS PROCEDURE release; PROCEDURE main2(p_num_parents IN NUMBER, p_num_children IN NUMBER); END JAVA_MEMORY_TEST;
    CREATE OR REPLACE PACKAGE BODY JAVA_MEMORY_TEST AS PROCEDURE release AS LANGUAGE JAVA NAME 'mypackage2.app.release()'; PROCEDURE main2(p_num_parents IN NUMBER, p_num_children IN NUMBER) AS LANGUAGE JAVA NAME 'mypackage2.app.main2(int, int)'; END JAVA_MEMORY_TEST;
    declare
    number breakpoint_var
    begin
    -- Call the procedure
    breakpoint_var := 0;
    java_memory_test.main2(30, 50);
    breakpoint_var := 1;
    java_memory_test.release();
    breakpoint_var := 2;
    end;

    When run in Oracle the resources are not released. Is there somthing special that needs to
    be called to get the garbage collector to do it's job when running in an Oracle database?Curious - I was always under the impression that you can not force garbage collection. All you could do was request it, and the JVM was free to do that when it was "good 'n ready", usually in a separate thread.
    I gather this from the API docs for system.gc() where it says "Calling this method suggests that the Java virtual machine expend effort ..." and the word "suggests" imlies that it is not required to run.

  • Entity Beans not getting garbage collected

    Hi,
    I am developing an application that is using EJBs utilizing several common design patterns (i.e. Session Facade, DAO, and Fast Lane Reader). All of the patterns used have come from books by Sun Microsystems Press.
    As I have understood the pattern, the Session Facade pattern uses Stateless Session Beans (SLSB) to implement a desired functionality and accesses the entity beans locally. The results from the entity beans are placed into Value Objects and passed back to the client separating any direct access with the entity beans from the client. In my case, I am using BMP for my entity beans.
    The problem I am seeing with Optimizeit is that none of my entity beans are getting garbage collected despite no references to them. The SLSB creates what entities it needs to perform a task at the local level, puts the data into a value object and goes out of scope.
    Shouldn't the entity beans get removed if the object that references them has gone away or am I missing something?
    Is there a proper way to set an entity bean (or any EJB for that matter) for garbage collection.
    thanks in advance for any help...

    You might even discover that entity beans can get created even before you use them.
    Your application server creates "pools" of bean instances that it can use when it needs to. It is part of this role, and is done in order to optimize performances.
    You cannot force them to be garbage collected. Even if you stop referencing them, the app server will.
    When your create references to a bean, it (usually) won't create an instance. It will take an existing one, and load data into it, using ejbCreate or ejbActivate.
    Hope this helps.
    /Stephane

  • Surviving garbage collection

    I have a number of forms that use functionality encapsulated in script variables. These script variables have state in them, that must survive between calls. However, SpiderMonkey's GC disagrees, causing issues when objects that are supposed to be initialized disappears. I know there are some workarounds for this, but I worry that none of them are documented by Adobe. Many of these forms are used by third parties and must continue to work from year to year and version to version of Reader. Does anyone have suggestions?

    personal opinion really. I do call garbage collection destruction, the memory occupied by the objects in question is reclaimed. It is a discussion point however as it is from the perspective of the JVM; from the perspective of the application the object is "destroyed" as soon as you cut all references to it.
    What to explain about finalize()? It is invoked right before an object is garbage collected, possibly allowing you to do some last minute clean up jobs, like letting go of resource handles and such. The general rule about it is that in 99.99% of the cases you need not touch it. If you have a design where you need it, it is best to assume the design is wrong and you need to change it. For example in the case of closing resources, it is better to have a close() method that needs to be invoked manually.
    If you do use it, you better be really sure that you know what you are doing as you may cause performance problems or even hard to trace unexpected behavior.

  • 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.

Maybe you are looking for