IO objects abandoned while still open will call close() in their finalizer. Taking advantage of this behavior, MRI guards every fd allocating syscall retrying the syscall after running the GC if EMFILE/ENFILE are encountered:

https://github.com/ruby/ruby/blob/trunk/io.c#L5449-L5454
https://github.com/ruby/ruby/blob/trunk/dir.c#L485-L489
https://github.com/ruby/ruby/blob/trunk/ext/socket/socket.c#L243-L246

This is possible in MRI because rb_gc() blocks while the GC runs, guaranteeing that finalizers will have been invoked before the syscall is retried. System.gc() doesn't block, however, so this approach on the JVM will always fail.

The guards in jruby are also incomplete. As best I can tell they only exist around sysopen call, but don't exist around other descriptor allocating calls (directories, sockets, etc)

It seems to me that jruby could do one of several things:

1. Remove the gc invocation and the sysopen retries (this PR). This should cause reliable failures when open IO objects accumulate.
2. Remove the sysopen retries, but still invoke the gc. This should cause intermittent failures when open IO objects accumulate. My concern is this scenario may be more difficult to diagnose.
3. Add this guard around the remaining descriptor allocating syscalls. Same concerns as option Project suggestions #2.

I don't know of a good way to emulate the behavior of MRI in this case, unfortunately.