RE: Memory Management

New Message Reply Date view Thread view Subject view Author view

From: Dorosky, Christopher G (christopher.g.dorosky++at++lmco.com)
Date: 06/27/2001 15:28:23


Are you sure that you want to reference gset after doing a delete on it?

I also noticed that you can run performer out of memory in seconds (on a
machine with gigabytes of memory) if you simply create pfGeoSets (with
attributes) and delete them.

There is some bookkeeping that is screwed up, unless you add the pfGeoSet to
a geode, and I think you might have to add the geode to the screen, I don't
remember.

That's normally not a terribly useful thing to do, but when writing sample
programs on memory management, it is good to know.

The above was tested with 2.2.x It may be fixed in 2.4.1

Chris

Christopher Dorosky
Lead Electronic Systems Engineer - Real Time Simulation
Lockheed Martin Missiles and Fire Control - Dallas
christopher.g.dorosky++at++lmco.com
972-603-2349

-----Original Message-----
From: Michael Lewis [mailto:mlewis++at++evl.uic.edu]
Sent: Tuesday, June 26, 2001 3:57 PM
To: info-performer++at++sgi.com
Subject: Re: Memory Management

Hello

I wrote a simple program to test out memory management, and it turns out
when
traversing through the nodes and doing a delete/ unrefDelete, or
delete/ checkDelete on the
geosets in the pfNode tree (created using pfdLoadFile) , the shared
memory still does not
update. I did a amallinfo before and after
the recursive deletion and still the available shared memory didnt
change.

Also I tried traversing a pfNode tree and doing a getSize on the geosets
in the
pfNode and I received a total size of 0.

This test was done loading one pfNode at a time getting the size before
and after,
And deleting one pfNode at a time then getting
the size before and after

So I am still unsuccessfull in finding what the true free memory
available is after a recursive deletion of a node.
And I still cant find what the true memory size of a loaded object is
after recursively calling getSize on its geoSets. Any
suggestion, or is this a flaw of Performer.

Here are the two main functions I used for traversing the tree and
deleting and
traversing the tree and getting the size.

Thanks

Mike

void traverseDelete(pfNode *node)
{
 int i;
 if (node->isOfType(pfGeode::getClassType()))
 {
        pfGeode *geode = (pfGeode *)node;
        for (i=0; i < geode->getNumGSets(); i++)
         {
                     pfGeoSet *gset = geode->getGSet(i);
                     delete(gset);
                     int val = FALSE;
                     // while ( !(val == TRUE))
                     val = gset->unrefDelete();

                     if (val == TRUE) printf("Geoset %d from %d sets has
been deleted \n",i,geode->getNumGSets());
         }
 }
 else if (node->isOfType(pfGroup::getClassType()))
  {
        pfGroup *group = (pfGroup *)node;
        for (i=0; i < group->getNumChildren(); i++)
                {
                traverseDelete(group->getChild(i));
                }
   }
}

void getMemSize(pfNode *node)
{
      int i;
      if (node->isOfType(pfGeode::getClassType()))
      {
              pfGeode *geode = (pfGeode *)node;
              for (i=0; i < geode->getNumGSets(); i++)
                {
                pfGeoSet *gset = geode->getGSet(i);
                int geoSetSize = gset->getSize();
                printf("Geoset %d from %d size is %d
\n",i,geode->getNumGSets(),geoSetSize);
                totalSize = totalSize + geoSetSize;
                }
         }
      else if (node->isOfType(pfGroup::getClassType()))
      {
               pfGroup *group = (pfGroup *)node;
               for (i=0; i < group->getNumChildren(); i++)
                {
                getMemSize(group->getChild(i));
                }
        }

}

--
  Michael J. Lewis
  mlewis++at++evl.uic.edu
-----------------------------------------------------------------------
 List Archives, FAQ, FTP:  http://www.sgi.com/software/performer/
Open Development Project:  http://oss.sgi.com/projects/performer/
             Submissions:  info-performer++at++sgi.com
         Admin. requests:  info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Jun 27 2001 - 15:27:15 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.