Explanation of Warnings From MRI's Test Suite

JRuby has, for some time now, run the same test suite as MRI (C Ruby, Matz's Ruby). Because not all tests pass, we use minitest-excludes to mask out the failures, and over time we unmask stuff as we fix it.

However, there's a number of warnings we get from the suite that are nonfatal and unmaskable. I thought I'd show them to you and tell their stories.

JRuby 1.9 mode only supports the `psych` YAML engine; ignoring `syck`

When we started implementing support for the new "psych" YAML engine that Aaron Patterson created (atop libyaml) for Ruby 1.9, we decided that we would not support the broken "syck" engine anymore. The libyaml version is strictly YAML spec compliant, and this is our contribution to ridding the world of "syck"'s broken YAML forever.

GC.stress= does nothing on JRuby

JRuby does not have direct control over the JVM's GC, and so we can't implement things like GC.stress=, which MRI uses to put the GC into "stress" mode (GCing much more frequently to better test GC stability and behavior). There are flags for the JVM to do this sort of testing, but since we don't really need to test the JVM's GC for correctness and stability, we have not exposed those flags directly.

This flag is used in a number of MRI tests to force GC to happen more often and/or to actually test GC behaviors.

SAFE levels are not supported in JRuby

JRuby does not support standard Ruby's security model, "safe levels", because we believe safe levels are a flawed, too-coarse mechanism. On JRuby, you can use standard Java security policies.

We have debated mapping the various Ruby safe levels to equivalent sets of Java security permissions, but have never gotten around to it.

GC.enable does nothing on JRuby / GC.disable does nothing on JRuby

There's no standard API on the JVM to disable the garbage collector completely, so GC.enable and GC.disable do nothing in JRuby.

It's also interesting to note that while you can request a GC run from the JVM by calling System.gc, JRuby also stubs out Ruby's GC.start. We opted to do this because GC.start is used in some Ruby libraries as a band-aid around Ruby's sometimes-slow GC, but the same call on JRuby is both unnecessary (because GC overhead is rarely a problem) and a major performance hit (because it triggers a full GC over the entire heap).