i'm hoping the nice folks on this mailing list can help me. i am working on a project that needs a discrete event simulator. conceptually, we will have lots of very lightweight threads, each of which will run until it determines it should give up control to another thread. due to the number and "lightness" of these threads, a JVM implementing solely native threads (e.g. Sun or IBM's offerings) just doesn't cut it performance-wise (this app will be running primarily on linux). luckily kaffe supports green threads.
i'm not sure why sun doesn't support green threads pst JDK-1.3, but they don't. i've tried a number of solutions with sun's JDK-1.4.2, including instrumenting the bytecode to implement continuations. then i found kaffe with its optional green thread implementation. i have a microbenchmark that spawns 25 or so threads, and each one runs for 50k iterations, updating some shared data structure. on this benchmark, kaffe's performance was remarkable. my hopes were high.
however, once i tried to run my full event simulator using kaffe, the performance went down the tubes. i have not been able to ascertain why exactly. the current implementation has all of the synchronization blocks one would need for a non-green thread implementation to avoid races. it also heavily uses a hashmap.
i'm writing in hopes that someone might have some insight as to what's going on, what to look for, or just how to find where the bottlenecks are. i don't mind reading code/docs. i just need a nudge or some insight, like i said.
also, are there any gui's for viewing kaffe's gprof output?
thanks for any help, nall.
_______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
