[osg-users] How to avoid Javas Garbage Collection to free large data array elements ?

[Rafa Gaitan]

Hi Christian,

Dealing with the GC in Java is always a pain. Some time ago I worked doing
some JNI libraries with OSG and we had problems with the GC don't freeing
"small" objects in Java (wrappers for big C++ objects). In the end the more
you can do in the native part the better if you need performance and an
strict memory control.

For the android I recommend you take a look to the osgjni sample:
https://github.com/miragetech/osgAndroid/tree/master/org.openscenegraph.osgjni

The purpose of this sample was making "complex"  things that were not
supported in the JNI wrapper. As you can see in the Activity:

Node node = ReadFile.readNodeFile(path);
MatrixTransform m = new MatrixTransform();
m.addChild(node);
mView.setSceneData(OSGConfiguration.configureScene(m));

The osgAndroid library is used for loading a node but then before setting
the scene to the viewer I call to a "OSGConfiguration" class that is
another JNI wrapper in the current project:
https://github.com/miragetech/osgAndroid/blob/master/org.openscenegraph.osgjni/src/org/openscenegraph/osgjni/OSGConfiguration.java
https://github.com/miragetech/osgAndroid/blob/master/org.openscenegraph.osgjni/jni/JNIOSGConfiguration.cpp

This creates a simple animation with OSG in the native part, I think a
similar approach could be used for you, avoiding all the GC thing. You can
also create new wrappers of your own classes following the same schema used
in osgAndroid if you think it could be useful :).

I hope it helps!

Regards,
Rafa

El jue., 30 jul. 2015 a las 20:35, Christian Kehl (<christian-kehl at web.de>)
escribió:

> Hi to everyone,
>
> I currently extend the osgAndroid project (attempt) to do Texture
> Projection and Mapping with mobile images. I already extended the codebase
> so to get access to the geometry, Vector Arrays etc. of a loaded geometry.
> Now, the geometry loading function looks as follows:
>
>
> Code:
>
> private void _load_geometry()
> {
>   Node mesh_node = ReadFile.readNodeFile(pointcloud_path);
>   mesh = new Group(mesh_node.getNativePtr());
>   Geode mesh_geode = new Geode(mesh.getLastChild().getNativePtr());
>   _drawable = new Geometry(mesh_geode.getLastDrawable().getNativePtr());
>   vertex_array = _drawable.getVertexArray();
>   Log.i("TEXTUREMAPPING", "Vertex array loaded");
>   geometry = new ArrayList<Point3>();
>   Log.i("TEXTUREMAPPING", "Geometry allocated");
>   for(int i = 0; i < vertex_array.size(); i++)
>   {
>     geometry.add(new Point3(vertex_array.get(i).x(),
> vertex_array.get(i).y(), vertex_array.get(i).z()));
>   }
>   Log.i("TEXTUREMAPPING", "Geometry set.");
>   geometry_as_matrix = new MatOfPoint3f();
>   Log.i("TEXTUREMAPPING", "Number of 3D points: " +
> Integer.toString(geometry.size()));
> }
>
>
>
>
> "geometry" is here an ArrayList of OpenCV's Point3. As you can see, In the
> for-loop I touch every element in the Vec3Array. The Vec3Array itself is a
> wrapped version of the original C++ class, accessed with its object
> pointer, as seen in this JNI wrapper code:
>
>
> Code:
>
> JNIEXPORT jlong JNICALL
> Java_org_openscenegraph_osg_core_Vec3Array_nativeCreateVec3Array(JNIEnv *,
> jclass)
> {
>   osg::Vec3Array *a = new osg::Vec3Array();
>   a->ref();
>   return reinterpret_cast<jlong>(a);
> }
>
>
>
>
> Now, the trouble: with a certain geometry (test:40k vertices), the test
> message of actually accessed elements ["Number of 3D Points:"
> geometry.size(), see above] prints ~11k vertices. In the java console logs
> (LogCat), I see that Java's GC "cleared" its memory two times during the
> upper function execution.
>
> My question: How can I avoid it ? How can/should I do the per-Vertex
> operations ? Has anybody encountered problems with Java's GC formerly,
> either in former Android wrappers or in old Java platform portations ?
>
> The internet with several blogs and lectures tells me there is (especially
> with Android) no way to actually "control" the GC, or protect certain
> objects from not being freed. The only option mentioned is to code the
> things in JNI (C++), as the Garbage Collector obviously doesn't operate on
> the C++ code.
>
> Opinions and suggestions are welcome.
>
> Cheers,
> Christian
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64536#64536
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150730/e9ac9c9d/attachment-0002.htm>