Closed
Conversation
ThreadFiber instance. So, for every ThreadFiber instance that got garbage collected another one was created. This behavior can lead to the finalizer queue filling up as quickly as it's emptied under heavy memory pressure and the JVM grinding to a halt.
Contributor
Author
|
There may be a better way to fix this than what I'm doing here. This is just one solution I came up with late at night. |
Member
|
Yeah, I'm doing the uberfix that resolves this issue and also cleans up the fiber threads properly. With tests, even :-D |
headius
added a commit
that referenced
this pull request
Oct 3, 2013
There are several fixes here to ensure that fibers finalize in a consistent and clean way. * Direct delivery of the kill event to the target thread. Without this change, the delivery process caused another ThreadFiber object to come to life, keeping objects alive and endlessly finalizing. Delivering the event via ThreadService caused the finalizer thread to participate in Ruby thread events, which we do not want. The new version delivers the event directly via a special "dieFromFinalizer" method added to RubyThread. * Make a better effort to kill the thread. The original code just shut down the fiber's queue and delivered a kill event. The new logic does both of those as well as interrupting both the RubyThread and the java.lang.Thread in case the fiber is waiting on some other blocking call. We could go the next step and try to forcibly Thread.stop, but that has not been necessary yet. * Ensure that the fiber thread never has on-stack references to the fiber object In order for the fiber object to be GCable and finalizable, there must be no live references to it. This includes references on the fiber thread's execution stack, such as those surrounding the yield method's call to queue.pop. In the new logic, no hard references to the ThreadFiber object appear anywhere in code, and the fiber object is eventually GCed and finalized as expected. * Test to ensure that fibers are getting cleaned up This commit also adds a test that attempts to spin up 10000 fibers and checks that they are cleaned up by comparing pre-test and post-test native thread counts. This should help ensure we do not regress on fiber lifecycle in the future.
Member
|
Uberfix has landed! |
chrisseaton
added a commit
that referenced
this pull request
Jan 31, 2014
Contributor
|
This seems to be broken. It hangs for a while and then we get an exception in what looks like the fiber system shutdown. I've commented it out in 383df3c and it was causing the build to error (timeout). |
headius
added a commit
that referenced
this pull request
Feb 22, 2014
Fiber started to get GCed and shut down, but then woke up and tried to yield. If a fiber yielding control has its own queue shut down, allow exception to propagate normally.
Member
|
There were issues with the GH-1075 spec but I'm not sure they were related. In any case, we've had everything green since this PR was reopened, so I'm re-closing. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ThreadFiber's finalizer was triggering the creation of a new ThreadFiber instance. So, for every ThreadFiber instance that got garbage collected another one was created.
This behavior can lead to the finalizer queue filling up as quickly as it's emptied under heavy memory pressure and the JVM grinding to a halt.
This fixes the issue with TorqueBox integration tests under JRuby 1.7.5 hanging when they didn't under 1.7.4.