[CsMain] Bugs in Crystal Space CVS Repository as of a Few Days Ago

[Paul Snively]

Folks,

I finally checked out CS and began looking at it in earnest. In so doing,
I've discovered a few places where the classic C++ error of not matching
your news to your deletes and your new[]s to your delete[]s occur.

In csSoundData::Clean():

CHKB (delete (UByte *)Data);

needs to be:

CHKB (delete[] (UByte *)Data);

In csSpriteTemplate::ComputeNormals():

CHK (delete tri_normals);

needs to be:

CHK (delete[] tri_normals);

In csVFS::~csVFS():

CHK (delete cwd);

needs to be:

CHK (delete[] cwd);

In the Blocks application, HighScore::~HighScore():

delete names[i];

needs to be:

delete[] names[i];

So far, these four instances are all I've found, but collectively they
resolve serious crashing bugs in Blocks and Walktest. I've observed other
bugs (halos in Mac OpenGL are black rather than white, as is text; in
Walktest using flarge.zip and the software renderer, the revolving conjoined
circular wood-textured items show a "rainbow" effect at the edges at certain
points in their rotation), but those aren't system crashers, whereas the
above-mentioned incorrect C++ definitely is.

Anyway, I'm having fun with my initial digging--thanks for a great tool!

Oh, BTW: if I want to try my hand at integrating CS into Java using JNI,
where would I start? Anyone else already looking at this?

Best regards,
Paul Snively

[Michael Dale Long]

Post by Paul Snively
Oh, BTW: if I want to try my hand at integrating CS into Java using JNI,
where would I start? Anyone else already looking at this?

I'm not sure what you mean by integrating CS into Java, nor what JNI is,
but if what you mean is using Java as an extensible scripting language for
CS, you might check out the CrystalClear project. It's aimed at providing
a plugin framework that will include scripting plugins. Currently a
Python scripting plugin is planned, but a Java one would be a possibility.

http://crystalclear.sourceforge.net/

-Michael

[Greg Caulton]

JNI is the Java Native Interface, used to execute native methods.
So if Crystal Space could be compiled into a dynamic linked library with the
appropriate functions available, in Java you would have
System.load("cs.dll");
and then be able to execute those functions as Java methods.

While I tested individual functions, I'd be interested to know whether you can
access C++ objects.

Michael, I'd certainly be interested in helping with any plugin scripting work
w/ Crystal Clear that would use Java.

Greg

Post by Michael Dale Long

Post by Paul Snively
Oh, BTW: if I want to try my hand at integrating CS into Java using JNI,
where would I start? Anyone else already looking at this?

I'm not sure what you mean by integrating CS into Java, nor what JNI is,
but if what you mean is using Java as an extensible scripting language for
CS, you might check out the CrystalClear project. It's aimed at providing
a plugin framework that will include scripting plugins. Currently a
Python scripting plugin is planned, but a Java one would be a possibility.
http://crystalclear.sourceforge.net/
-Michael
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main

[Jim Torelli]

The only fear with that is the JNI doesn't jive well with native threads.
If you're thinking of trying to use JNI in a processor intensive process
with multiple threads, you'll probably run into massive preformance
problems, not to mention irregualar thread synchronization between the
native OS and the java vm.


Jim

Post by Greg Caulton
JNI is the Java Native Interface, used to execute native methods.
So if Crystal Space could be compiled into a dynamic linked library with the
appropriate functions available, in Java you would have
System.load("cs.dll");
and then be able to execute those functions as Java methods.
While I tested individual functions, I'd be interested to know whether you can
access C++ objects.
Michael, I'd certainly be interested in helping with any plugin scripting work
w/ Crystal Clear that would use Java.
Greg

Post by Michael Dale Long

Post by Paul Snively
Oh, BTW: if I want to try my hand at integrating CS into Java using JNI,
where would I start? Anyone else already looking at this?

I'm not sure what you mean by integrating CS into Java, nor what JNI is,
but if what you mean is using Java as an extensible scripting language for
CS, you might check out the CrystalClear project. It's aimed at providing
a plugin framework that will include scripting plugins. Currently a
Python scripting plugin is planned, but a Java one would be a possibility.
http://crystalclear.sourceforge.net/
-Michael
_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main

_______________________________________________
Crystal-main mailing list
http://lists.sourceforge.net/mailman/listinfo/crystal-main

[Artur Biesiadowski]

Post by Jim Torelli
The only fear with that is the JNI doesn't jive well with native threads.
If you're thinking of trying to use JNI in a processor intensive process
with multiple threads, you'll probably run into massive preformance
problems, not to mention irregualar thread synchronization between the
native OS and the java vm.

I don't think that synchronization would be a problem. As far as
performance is concerned, my main fear would be java gc - it would pop
in once per some time and stop entire process. Having 0.1s breaks every
few seconds is not a good thing for 3d game.

BTW, if we are on topic of scripting, then I'll suggest not booting and
setting up all crystalspace environment from java, but using java
classes/objects as event listeners for various things, called from
inside cs engine. For example attach java object to actor which would
react on collisions, timer etc. Then in world file you just name which
classes/listeners should be attached to which cspace object.

With some tricks, we might be able to do almost completely without java
gc - or with running it only once per few minutes (which should be
acceptable - maybe during level switch or inactivity of players).

Artur

[jorrit]

Post by Paul Snively
Folks,
I finally checked out CS and began looking at it in earnest. In so doing,
I've discovered a few places where the classic C++ error of not matching
your news to your deletes and your new[]s to your delete[]s occur.

Thanks for reporting these bugs. We will fix them asap.

Post by Paul Snively
So far, these four instances are all I've found, but collectively they
resolve serious crashing bugs in Blocks and Walktest. I've observed other
bugs (halos in Mac OpenGL are black rather than white, as is text; in
Walktest using flarge.zip and the software renderer, the revolving conjoined
circular wood-textured items show a "rainbow" effect at the edges at certain
points in their rotation),

That's a known bug. It is also listed on the SF bug forum.

Post by Paul Snively
but those aren't system crashers, whereas the
above-mentioned incorrect C++ definitely is.
Anyway, I'm having fun with my initial digging--thanks for a great tool!

No problem.

Post by Paul Snively
Oh, BTW: if I want to try my hand at integrating CS into Java using JNI,
where would I start? Anyone else already looking at this?

I'm also very interested in this but didn't manage to do this due to lack
of time and other priorities. But I'm interested in helping you with this.
I suggest trying to wrap the most important classes in JNI first. These being
csWorld, csSector, csThing, csCamera, and a few others.

Then we can go on from there.

Maybe you should have a look at the 'simple' app and see if you can try
to port that to Java. i.e. try to implement the minimal JNI interface that
will enable apps like simple to work. Then we can improve on that.

Greetings,

[Peter Ashford]

Post by Artur Biesiadowski

Post by Jim Torelli
The only fear with that is the JNI doesn't jive well with native threads.
If you're thinking of trying to use JNI in a processor intensive process
with multiple threads, you'll probably run into massive preformance
problems, not to mention irregualar thread synchronization between the
native OS and the java vm.

I don't think that synchronization would be a problem. As far as
performance is concerned, my main fear would be java gc - it would pop
in once per some time and stop entire process. Having 0.1s breaks every
few seconds is not a good thing for 3d game.
BTW, if we are on topic of scripting, then I'll suggest not booting and
setting up all crystalspace environment from java, but using java
classes/objects as event listeners for various things, called from
inside cs engine. For example attach java object to actor which would
react on collisions, timer etc. Then in world file you just name which
classes/listeners should be attached to which cspace object.
With some tricks, we might be able to do almost completely without java
gc - or with running it only once per few minutes (which should be
acceptable - maybe during level switch or inactivity of players).
Artur

I think that the 'Hotspot' engine from Sun can fix this issue with GC
somewhat - according to the white paper on the technology, you can choose
between a phased GC like you mention above, or you can get the VM to GC
continuously which supposedly works better for real time code.

There's a Linux Hotspot engine, too.

Peter.

[Artur Biesiadowski]

Post by Peter Ashford
I think that the 'Hotspot' engine from Sun can fix this issue with GC
somewhat - according to the white paper on the technology, you can choose
between a phased GC like you mention above, or you can get the VM to GC
continuously which supposedly works better for real time code.

I've dones some tests on SVG Viewer and yes, it should be enough. Here
is data - first for normal gc, second for incremental one. IT is not for
exactly same process - program is interactive, but should give general
idea about time proportions. With normal gc there are Full GC stops,
which would be disruptive (0.2s). With incremental gc most breaks are
under 0.02s, so it should be not noticeable.


Normal gc:

[GC 511K->204K(1984K), 0.0251898 secs]
[GC 716K->340K(1984K), 0.0158425 secs]
[GC 852K->434K(1984K), 0.0082938 secs]
[GC 448K->439K(1984K), 0.0068749 secs]
[GC 1075K->1034K(1984K), 0.0084740 secs]
[Full GC 1034K->1034K(2300K), 0.1096465 secs]
[GC 1653K->1624K(2300K), 0.0044310 secs]
[Full GC 1624K->1037K(2308K), 0.1154956 secs]
[GC 2215K->1763K(2308K), 0.0052197 secs]
[GC 2275K->1903K(2436K), 0.0139979 secs]
[Full GC 2415K->1913K(3676K), 0.1386086 secs]
[GC 2357K->1929K(3676K), 0.0211871 secs]
[GC 2441K->2225K(3676K), 0.0102927 secs]
[GC 2737K->2375K(3676K), 0.0185127 secs]
[GC 2887K->2479K(3676K), 0.0054292 secs]
[GC 2980K->2544K(3676K), 0.0048073 secs]
[Full GC 2544K->774K(3676K), 0.2074775 secs]
[GC 1756K->1707K(3676K), 0.0012957 secs]
[GC 3030K->2523K(3676K), 0.0032904 secs]
[GC 3035K->2553K(3676K), 0.0041310 secs]
[GC 3065K->2530K(3676K), 0.0016435 secs]
[GC 3041K->2530K(3676K), 0.0021539 secs]
[GC 3041K->2537K(3676K), 0.0016611 secs]
[GC 3049K->2545K(3676K), 0.0028487 secs]
[GC 3057K->2648K(3676K), 0.0071816 secs]
[GC 3160K->2708K(3676K), 0.0066645 secs]
[GC 3220K->2725K(3676K), 0.0038745 secs]
[GC 3236K->2785K(3676K), 0.0040539 secs]



Incremental gc:
[GC 511K->204K(768K), 0.0252058 secs]
[GC 716K->348K(960K), 0.0178950 secs]
[GC 860K->415K(1024K), 0.0107436 secs]
[GC 425K->418K(1024K), 0.0093314 secs]
[GC 1054K->1005K(1664K), 0.0115523 secs]
[GC 1684K->1009K(1664K), 0.0067366 secs]
[GC 2247K->1821K(2432K), 0.0137993 secs]
[GC 2333K->1957K(2560K), 0.0183971 secs]
[GC 2465K->1996K(2624K), 0.0149542 secs]
[GC 2508K->1983K(2624K), 0.0179923 secs]
[GC 2495K->2577K(3008K), 0.0121474 secs]
[GC 2832K->2722K(3008K), 0.0111534 secs]
[GC 2893K->2840K(3072K), 0.0232102 secs]
[GC 2968K->2862K(3200K), 0.0080734 secs]
[GC 2990K->2882K(3200K), 0.0056873 secs]
[GC 3010K->2881K(3200K), 0.0075797 secs]
[GC 3009K->2907K(3200K), 0.0095032 secs]
[GC 3035K->2913K(3264K), 0.0067266 secs]
[GC 3041K->2922K(3264K), 0.0089970 secs]
[GC 3049K->2929K(3264K), 0.0109900 secs]
[GC 3057K->2926K(3264K), 0.0086332 secs]
[GC 2972K->2888K(3264K), 0.0059203 secs]
[GC 3669K->3500K(3904K), 0.0075085 secs]
[GC 4369K->3867K(4544K), 0.0104896 secs]
[GC 4104K->1882K(2688K), 0.0061717 secs]
[GC 2678K->2628K(3392K), 0.0022000 secs]
[GC 3758K->3246K(3968K), 0.0067257 secs]
[GC 3758K->3268K(3968K), 0.0030088 secs]
[GC 3780K->3248K(3968K), 0.0025487 secs]
[GC 3760K->3256K(3968K), 0.0058792 secs]
[GC 3412K->3247K(3968K), 0.0015832 secs]
[GC 4073K->4018K(4736K), 0.0013493 secs]
[GC 5201K->3385K(4032K), 0.0147715 secs]
[GC 3897K->3502K(4096K), 0.0084765 secs]
[GC 4011K->3543K(4160K), 0.0076560 secs]
[GC 4055K->3592K(4224K), 0.0107000 secs]

Post by Peter Ashford
There's a Linux Hotspot engine, too.

Not yet AFAIK.

Artur

[Peter Ashford]

Post by Artur Biesiadowski

Post by Peter Ashford
There's a Linux Hotspot engine, too.

Not yet AFAIK.

Yup - you're right. I just checked the Sun site -there's work being done
between Sun and Caldera to produce a hotspot engine for Linux, but it's
not due till 'later this year'

Peter.