Hi Raffi:

I have been very much intending to pose this question to this Forum, but
was a wee hesitant since I thought this could be considered a little OT.
I do believe that object pooling or some such memory management is
a necessity with Java/Java3D graphics, though I am aware that there is
a dichotomy of opinions on this issue. In my app., I have to go to
great lengths to minimize object creation during numerically intensive
animations.

I use object pools in some crucial parts of my app., especially for
Appearance, Point3*, arrays etc.

A suggestion on your approach - you could hold your Transform3D's as
"Weak References" - when your memory limit reaches a panic stage,
Java would automatically flush the stack. With this approach, of course,
you need to check each time if your pool is indeed available
each time you want to draw off a transform3D from it. Also, in general
with object pooling, great discipline is required in properly clearing
all references to the object when it is being returned to the pool. This
is not as easy as it might seem.

While at it, some questions that I have are:

1. Do Sun Java programmers favor object pooling in general - though
object creation times with Java have in recent times become competitive
with C++, time spent on garbage collection is still an issue.

2. Can objects such as Branch/Transform Groups, Shape3Ds, Geometry Arrays
etc. be completely restored to their primitive original state with just
a single function call ( for clearing previously set/unset capability
bits etc. ).

3. The Animation API in Java3D uses Point3* objects exclusively in some
places (correct me if I am wrong ). I had posted a request a while
back that these be converted to primitive arrays just as in
geometry arrays.

4. Relevant to point 3 above, assuming that one does implement an
object pooling facility, would it be more efficient to deal with
Point3Ds rather than primitive arrays ( assuming that the time involved
in creating a minimum-sized-starting-pool can be tolerated ).

May be there are other people as well who may be interested or have
some expert opinions. In case you are not aware of, JavaWorld has some
articles on Object Pooling that you may find quite useful.

Regards

Raj Vaidya



>On Thu, 20 Dec 2001 14:42:40 -0500, Kasparian, Raffi J. <[EMAIL PROTECTED]> 
>wrote:

>Hi all,
>
>In the interests of speeding up my J3D applications, I'm considering the
>pros and cons of the following approach to avoiding memory allocations and
>garbage collections. I have created a class called MemoryPool that handles
>requests for Transform3Ds (for instance) by returning from a pool of
>Transform3Ds an already created Transform3D that is no longer in use. The
>calling method could use it and then return it back to the pool of
>Transform3Ds free to be used again.
>
>public class MemoryPool{
>
>    protected static final Stack transform3Ds = new Stack();
>
>    static public Transform3D getTransform3D(){
>        synchronized( transform3Ds ){
>            if( transform3Ds.isEmpty() ){
>                transform3Ds.push( new Transform3D() );
>            }
>            return (Transform3D)transform3Ds.pop();
>        }
>    }
>    static public void returnTransform3D( Transform3D T ){
>        transform3Ds.push( T );
>    }
>}
>
>As an example of usage, the following method
>
>public doSomething(){
>    Transform3D T = new Transform3D();//causes memory allocation
>    //do something
>}//now eligible for garbage collection
>
>would be written as
>
>public doSomething(){
>    Transform3D T = MemoryPool.getTransform3D();//no memory allocation
>    //do something
>    MemoryPool.returnTransform3D( T );//no garbage collection
>}
>
>Please, I am very interested in feedback.
>
>Thanks,
>
>Raffi
>
> ==========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff JAVA3D-INTEREST".  For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to