Skip to content

Why JRuby?

Lloyd Dilley edited this page Mar 20, 2015 · 4 revisions

Why JRuby?

This page should now be considered historical. It was written when RubIRCd only featured threaded I/O.

RubIRCd should run fine on CRuby/MRI/YARV and other implementations with a global interpreter lock or GIL. RubIRCd does not make use of any external gems (EventMachine and Celluloid are optional) or special calls to the Java API. However, since RubIRCd makes use of multiple threads (one for each client connection, one for each initial connection during registration for the timer, and another background thread for periodically checking user activity), we recommend using JRuby which is not subject to the limitations of the GIL.

If you are running a busier server with many simultaneous client connections, JRuby should yield more performance. There are also some nice optimizations you can do with the JVM such as running in server mode, using the --fast argument, and enabling thread pooling/thread reuse. Lastly, there is the security benefit of the JVM sandbox architecture. The only downside is that you can likely expect the JVM to eat more RAM than CRuby/MRI/YARV. See JVM Tuning for more information. Lastly, SSL/TLS are not supported when using EventMachine with JRuby.

Clone this wiki locally