Charles Oliver Nutter

jruby/jruby#9038 adds several manifest entries to open packages and allow native access, which may mitigate this somewhat. However I believe this is mostly an issue with the native launcher on...

Yes I just got into a heap dump as well and it appears that there's a tremendous amount of Float objects being stored in a Timeout::Request as well. The Request...

Seems as though the `Timeout::Request` instances are not getting cleaned up and the Queue they are inserted into has thousands of stale entries. Something is preventing them from getting removed.

I think this is a side effect of the new design of the Timeout library. The trigger here is having a very short timeout and multiple threads making timeout requests....

Other experiments: * With 100 threads, a timeout of 10ms, and the timeout block sleeping for 1ms it keeps up fine and hovers around 350 of memory (with no cap)....

Also worth noting that this case also runs just fine with our old Java-based ScheduledExecutor timeout impl and never exceeds 500MB for me even with 100 threads running. The new...

@jsvd I have marked this for 9.4.10.0 because it is a contrived case unlikely to affect real-world applications and it's an issue in Timeout that will have to be researched...

I can't say where I stand right now... I also prefer the predictability and stability of our old Java timeout impl, but we want to be able to use the...

@jsvd I'm going to punt any further work on this for now. The issue as it stands is a flaw in the design of the `timeout` library (which can be...

An experiment in #8576 appears to make this a bit more robust as it reaches the JVM memory limit, but it does not prevent OOM at lower limits and still...