next »

[horati]

There was a recent performance related post in another thread.  It got me thinking about the strategic direction of memory usage in Xith.  Have you seen Javolution (http://www.javolution.com)?  It's a zero-garbage creation library; i.e., it was designed for the Java real-time environment.

Here are a few performance links related to it:

http://www.javolution.com/doc/benchmark.html
http://www.javolution.com/target/site/apidocs/index.html
http://www.javolution.com/target/site/apidocs/index.html

It seems like a good library to integrate into Xith and closely related projects over the next several years.  It is definitely aligned with the general goals of Xith; i.e., deterministic time followed by speed.  It has good support and a long list of projects that depend on it or automatically recognize its presence in the classpath to use it.

I should probably say that I have been using it for several months.

[Marvin Fröhlich]

Before I started to create the vecmath2 package in OpenMaLi I had contact to Javolution's author and wrote and gave him a couple of classes, that I needed for the Xith integration. He rejected them. The API seemed quite complicated to me and I couldn't say it was zero garbage creating. Well, maybe it has improved.

I was very willing to use some kind of a standard math library, which is feature rich like Javolution and doesn't produce that hell of garbage like Sun's vecmath does. And I really thought, Javolution was that lib, if only these classes would have been accepted.

There are still plans for a Xith 2.0 after we finally had the time to finish some missing features and improvements in Xith. Maybe this is a good time for a switch to Javolution, if it has improved compared to three years ago (or so). But for now I don't want a massive API change like that.

But be assured, that I will keep that in mind. One more API, that we don't have to maintain ourselves, is a good thing, if it serves our needs.

Marvin

[horati]

I don't think they'll ever incorporate OpenMaLi; however, OpenMaLi and Xith3D could become yet two more projects using Javolution.  They're pretty close to zero garbage AFAIK although I haven't seriously challenged their claims.  Some of it is a complicated API and some of it is quite simple.  As a drop-in replacement for java.util collections, it's very close to zero effort.  There are only a few methods like FastTable.setSize() instead of ArrayList.ensureCapacity() and ArrayList.trimToSize() to worry about.  So far, that has been the only way I have used it.

I was just thinking of a lot of the work we have in GC-friendly collections/pools.  As you say, it's always better to re-use another project's implementation so we have less to maintain... if their implementation is good enough.

The complicated stuff seems to be the contexts which I have avoided due to lack of time.  It looks very interesting and reminiscent of some of the good things we used to be able to do in C++.  Without any kind of expert understanding of Javolution contexts, I was thinking that you might be able to replace several hundred calls to Tuple3fPool.free() with a tiny number of stackContext.exit() calls.  Besides having them maintain another subset of functionality for us, that kind of savings eliminates a lot of potential memory leak bugs.

Glad to know you already looked at them once.

[Marvin Fröhlich]

I will definitely have a second closer look at Javolution when the time comes for Xith 2.0. But for now we really shouldn't open another construction site while we don't even have time for the undone stuff.

Marvin

[horati]

Cool.  I plan to become more serious with it over the next year.  Based on the timeline you list, I should be able to help with an analysis, and maybe implementation for 2.0.