JRuby compatiblity

[headius]

In response to a conversation on r/ruby I threw the HexaPDF test suite at JRuby.

Two strscan issues came out of it: ruby/strscan#150 and ruby/strscan#153

Most of the signing tests fail due to missing sign_raw support in jruby-openssl (which may or may not be compatible with Java cryptography APIs we use): jruby/jruby-openssl#332

Excluding those, two failures remain.

The first is a test of ObjectSpace.each_object which must be enabled in JRuby for full functionality (due to the extremely high cost of tracking all heap objects when the JVM provides no such facility):

HexaPDF::ImageLoader::PDF::load#test_0003_works for PDF files using a string object and use_stringio=false:
RuntimeError: ObjectSpace is disabled; each_object will only work with Class, pass -X+O to enable
    org/jruby/RubyObjectSpace.java:239:in 'each_object'
    test/hexapdf/image_loader/test_pdf.rb:40:in 'block in <main>'

Enabling ObjectSpace (with JRuby's -X+O flag) eliminates this failure.

The second appears to be a test that checks if OpenSSL::Cipher#update can accept empty bytes:

HexaPDF::Encryption::FastARC4#test_works_with_empty_strings:
ArgumentError: data must not be empty
    org/jruby/ext/openssl/Cipher.java:1111:in 'update'
    org/jruby/ext/openssl/Cipher.java:1096:in 'update'
    lib/hexapdf/encryption/fast_arc4.rb:65:in 'process'
    test/hexapdf/encryption/common.rb:88:in 'test_works_with_empty_strings'

This will need a fix in JRuby, but I wonder why it's being tested. 🤔

Overall functionality seems pretty solid in JRuby other than the lack of signing support via jruby-openssl.

[gettalong]

Thanks for looking at the failures!

The test for empty bytes is there because PDF objects may contain empty strings that need to be encrypted/decrypted. However, it would probably be better to check that elsewhere as it is unnecessary to go through the whole encryption/decryption process for an empty string. I will change that in HexaPDF (though this is still a compatibility problem with JRuby's OpenSSL implementation).

[headius]

Yeah we will fix that, probably by just ignoring blank strings pass into Cipher. Another trivial fix. I have not yet opened an issue for it.

[gettalong]

@headius With the new strscan release the general functionality of HexaPDF works and I ran some benchmarks. Due to the high start-up time JRuby is not directly comparable.

• How do you generally test the performance of JRuby against other Rubies?
• Is using 500MB of memory for a simple script the norm? I read through the JRuby wiki and it seems like this cannot easily be reduced.

[headius]

How do you generally test the performance of JRuby against other Rubies?

In general, run the benchmark repeatedly in the same process. JRuby will take longer than CRuby to reach a steady state, but anything that runs more than 10-20 seconds should get there.

I know the yjit benchmark harnesses do some amount of warmup so that might be a model to follow.

Is using 500MB of memory for a simple script the norm? I read through the JRuby wiki and it seems like this cannot easily be reduced.

The JVM is designed to use more memory to make GC run efficiently, based on the available memory in the system. It can be restricted using command line flags like -J-Xmx200M to limit the heap size to 200MB.

However... The JVM itself is a much larger runtime, and nearly all code that runs on it is JVM bytecode that must be loaded and parsed and optimized. The baseline size of a JRuby process will always be 75-150MB more than a CRuby process.

There is usually a tipping point where an app becomes large and complex enough that the better memory management in JVM wins. As an example, I ran the HexaPDF benchmark from YJIT and JRuby used less RSS than CRuby 3.4 by the end, nearly 30% less than CRuby with YJIT. That's the kind of tipping point I mean.