This is a feature of most common operating systems.

Basically, the process requests more memory from the OS and gets it,
uses it and then frees it, but does not return it to the OS.

(As an academic question, if someone knows about OS under active
development today that return memory from processes to the system, I'd
like to here about it)

There are two methods to help deal with memory:

java.lang.Runtime.totalMemory() 
"Returns the total amount of memory in the Java Virtual Machine."
java.lang.Runtime.freeMemory()
"Returns the amount of free memory in the system."

As the process runs, totalMemory will increase.  Each time
the process gets memory, freeMemory will increase.  As the process
uses the memory, freeMemory will decrease.
After a garbage collection happens, freeMemory will increase.

We modified the development tree so that it reports the amount
of memory used by tacking on the following code to the end of
ptolemy.actor.Manager.execute()

        // Report the execution time.
        long endTime = (new Date()).getTime();

        // Report memory usage statistics.
        Runtime runtime = Runtime.getRuntime();
        long totalMemory = runtime.totalMemory()/1024;
        long freeMemory = runtime.freeMemory()/1024;

        System.out.println("Manager.run(): Elapsed Time: "
                + (endTime - startTime) + " ms. Memory: "
                + totalMemory + "K Free: " + freeMemory + "K ("
                + Math.round( (((double)freeMemory)/((double)totalMemory))
                        * 100.0)
                + "%)");
    }


One cool thing to do is to use Ptolemy to plot the free and total
memory usage.  I added the following methods to
ptolemy/data/expr/UtilityFunctions.java:

    /** Return the approximate number of bytes available for future 
     *  object allocation.  Note that requesting a garbage collection
     *  may change this value.
     *  @return The approximate number of bytes available.
     *  @see #totalMemory
     */
    public static LongToken freeMemory() {
        return new LongToken(Runtime.getRuntime().freeMemory());
    }

    /** Return the approximate number of bytes used by current objects
     *  and available for future object allocation.
     *  @return The total number of bytes used by the JVM.
     *  @see #freeMemory
     */
    public static LongToken totalMemory() {
        return new LongToken(Runtime.getRuntime().totalMemory());
    }

Then I created a model that accesses totalMemory() and freeMemory()
as expression parameters and plots the results.  The model requires
a new actor called LongToDouble and the above changes to
UtilityFunctions, so redistributing the demo would be a little tricky,
but I can look into it.

We also hacked in a Tableau that has a plot of the memory usage and
a GC button.

-Christopher
--------


    Hi all ,
    i'm buliding complex models and i got an observation to be investigated
    that when i  wanna rerun the simualtion for a complex model , i found that
    the memory space reserved for the java.exe process still busy. it can't be
    released till i i exit ptolemy and restart it again .
    you can monitor that from the task manager to watch the running processes
    and the memory usage related to each. 
    you'll find that the space reserved for the java.exe still the same till i
    exit the ptolemy program and restart it back .
    it limits the flexibilty of running the simualtion for the same model more
    than one time to change the simulation parameters since we gotta create a
    free memory space for it by exiting the program and restart it back and
    open the model again ..
    So please if i you had the same problem or any one encountered it before
    let me know what is the reason ...?
    or how to overcome that headache .
    thank u 
    Regards, 
    MO. Salem 
    
    _____________________________________________
    Free email with personality! Over 200 domains!
    http://www.MyOwnEmail.com
    
    
    ---------------------------------------------------------------------------
   -
    Posted to the ptolemy-hackers mailing list.  Please send administrative
    mail for this list to: [EMAIL PROTECTED]
--------

----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list.  Please send administrative
mail for this list to: [EMAIL PROTECTED]

Reply via email to