On Wed, Nov 19, 2008 at 6:11 AM, Gordon Sim <[EMAIL PROTECTED]> wrote:
> Rajith Attapattu wrote: > >> Hi All, >> >> I have been testing the java client on particular RT jvm and have observed >> a >> stubstantial performance drop when compared to stock Java 1.5 >> After further investigation I changed the Threads in our java client to >> Realtime Threads and there was more than 50% improvement in performance. >> Using Realtime threads not only improves performance it also allows the >> user to fine tune the RT GC and other optimizations to get good >> determinism. >> >> At some point some of our Qpid users may want to run their applications on >> a >> RT jvm. To get the optimum benifit of such an environment we should >> provide >> a way for them to use RT Threads with a simple thread abstraction. For >> licensing reasons we cannot have any RT specific code in Qpid repo. >> So if we could provide a simple thread abstraction that defaults to >> java.lang.Thread that can be switched javax.realtime.RealtimeThread in an >> RT >> environment that would be great. >> >> I would like to hear your thoughts/suggestions around the best way to >> handle >> this. >> > > My first thought, would be to simply have a configurable implementation of > a ThreadFactory interface with a createThread(Runnable task, String > name):Thread method. The default would create normal threads, if a user > wished they could set a system property to indicate their prefered factory. > Some of our classes directly extends java.lang.Thread. So I believe the above strategy will be a bit difficult. > > Is there any difference in which threads are swapped to realtime threads? > I.e. is switching the io threads more effective than switching the > dispatcher, or do all the threads need to be switched to see any benefit? > You need to switch all threads to see a benifit. java.lang.Threads have a very low priority and is lower than RT GC threads even in the normal mode. Therefore when GC threads run it will completely preempt the java.lang.Threads which will cause a big slow down. (Note by default u will have a GC thread per CPU allocated). Also CPU is alocated based on priority and most of the time java.lang.Threads gets the short end of the stick and will cause the most jitter defeating the deterministic goals. So even of you limit GC threads, when GC runs the remaning CPU will mostly be allocated to the Realtime threads, and the java.lang.Threads will have very little CPU at all. > > Do you have a patch that you used for your experiments that would show the > scope of the changes required? > Hoping to attach one today for discussion. -- Regards, Rajith
