JRuby

CLONE -Threads created for Fibers/Generators/Enumerator.next must die due to GC and raise a nice error when threads are unavailable

Details

  • Number of attachments :
    0

Description

This bug is catching the remainder of the work from JRUBY-3964:

  • When Enumerator thread creation gets ahead of GC for dead enumerators+threads, we must have a mechanism for choking the rate of creation of new enumerator threads. My proposed way would be to use a weak reference queue to actively tidy up old enumerators+threads in the logic to create a new one; this will slow down creation to the speed at which GCable threads can be cleaned up.
  • When we reach a thread limit, we need to raise a nicer error. Right now the Java OOM error percolates out, killing the thread calling #next
  • 1.9's threaded Fibers need to be made GCable like 1.8.7's threaded Generators are now (due to fixes made for 1.4).

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Charles Oliver Nutter added a comment -

This is a clone of the previous bug (JRUBY-3964) to address a few additional points that were not critical enough for 1.4:

  • When Enumerator thread creation gets ahead of GC for dead enumerators+threads, we must have a mechanism for choking the rate of creation of new enumerator threads. My proposed way would be to use a weak reference queue to actively tidy up old enumerators+threads in the logic to create a new one; this will slow down creation to the speed at which GCable threads can be cleaned up.
  • When we reach a thread limit, we need to raise a nicer error. Right now the Java OOM error percolates out, killing the thread calling #next
Show
Charles Oliver Nutter added a comment - This is a clone of the previous bug ( JRUBY-3964 ) to address a few additional points that were not critical enough for 1.4: When Enumerator thread creation gets ahead of GC for dead enumerators+threads, we must have a mechanism for choking the rate of creation of new enumerator threads. My proposed way would be to use a weak reference queue to actively tidy up old enumerators+threads in the logic to create a new one; this will slow down creation to the speed at which GCable threads can be cleaned up. When we reach a thread limit, we need to raise a nicer error. Right now the Java OOM error percolates out, killing the thread calling #next
Charles Oliver Nutter made changes -
Field Original Value New Value
Affects Version/s JRuby 1.4 [ 15285 ]
Fix Version/s JRuby 1.5 [ 15792 ]
Fix Version/s JRuby 1.4 [ 15285 ]
Hide
Permalink
Charles Oliver Nutter added a comment -

FYI, also needed for this bug: get Fibers to GC like 1.8.7 generators are (from the previous bug). I will update description to reflect the actual tasks.

Show
Charles Oliver Nutter added a comment - FYI, also needed for this bug: get Fibers to GC like 1.8.7 generators are (from the previous bug). I will update description to reflect the actual tasks.
Charles Oliver Nutter made changes -
Description Currently we spin up a thread for fibers, generators, and enumerators that have had next or rewind called on them. This works well functionally, but with a hard reference from the containing object to the created thread, we're creating a situation where even after the fiber/generator/enumerator has been dereferenced, it and anything it references will stay alive because of the spun-up thread.

In addition, there are environments where it will be impossible to spin up threads, and we must produce a *friendly* error in those cases.

Both issues need to be fixed for this bug, to ensure our use of threads fits as cleanly as possible into all server types. 		This bug is catching the remainder of the work from JRUBY-3964:

* When Enumerator thread creation gets ahead of GC for dead enumerators+threads, we must have a mechanism for choking the rate of creation of new enumerator threads. My proposed way would be to use a weak reference queue to actively tidy up old enumerators+threads in the logic to create a new one; this will slow down creation to the speed at which GCable threads can be cleaned up.
* When we reach a thread limit, we need to raise a nicer error. Right now the Java OOM error percolates out, killing the thread calling #next
* 1.9's threaded Fibers need to be made GCable like 1.8.7's threaded Generators are now (due to fixes made for 1.4).
Hide
Permalink
Charles Oliver Nutter added a comment -

Moving to 1.6; there will be no additional work on Ruby 1.9 Fibers in this cycle.

Show
Charles Oliver Nutter added a comment - Moving to 1.6; there will be no additional work on Ruby 1.9 Fibers in this cycle.
Charles Oliver Nutter made changes -
Fix Version/s JRuby 1.6 [ 16275 ]
Fix Version/s JRuby 1.5 [ 15792 ]
Charles Oliver Nutter made changes -
Fix Version/s JRuby 1.6 [ 17062 ]
Fix Version/s JRuby 1.6RC1 [ 16275 ]
Hide
Permalink
Charles Oliver Nutter added a comment -

I checked a few scenarios:

  • Construct fiber, never resume it - ok; the fibers get collected before being fed into the executor, and so there's nothing to leak.
  • Construct fiber, run to completion - ok; fibers finish executing and get collected
  • Construct fiber, start it, but it does not complete - LEAKS; the fibers are kept alive by the executor thread

I started playing with some improvements to make the Fiber instance be GCable, but could not get it to shut down the thread. This is a fairly big deal if people are expecting to leave Fiber instances lying around, but if they are running them to completion they should be ok. I'm going to punt this to 1.6.1 since most changes I could make now would need more bake time than RC2 could provide.

Show
Charles Oliver Nutter added a comment - I checked a few scenarios: Construct fiber, never resume it - ok; the fibers get collected before being fed into the executor, and so there's nothing to leak. Construct fiber, run to completion - ok; fibers finish executing and get collected Construct fiber, start it, but it does not complete - LEAKS; the fibers are kept alive by the executor thread I started playing with some improvements to make the Fiber instance be GCable, but could not get it to shut down the thread. This is a fairly big deal if people are expecting to leave Fiber instances lying around, but if they are running them to completion they should be ok. I'm going to punt this to 1.6.1 since most changes I could make now would need more bake time than RC2 could provide.
Charles Oliver Nutter made changes -
Fix Version/s JRuby 1.6.1 [ 17085 ]
Fix Version/s JRuby 1.6 [ 17062 ]
Charles Oliver Nutter made changes -
Fix Version/s JRuby 1.6.2 [ 17306 ]
Fix Version/s JRuby 1.6.1 [ 17085 ]
Charles Oliver Nutter made changes -
Fix Version/s JRuby 1.6.3 [ 17374 ]
Fix Version/s JRuby 1.6.2 [ 17306 ]
Thomas E Enebo made changes -
Fix Version/s JRuby 1.6.4 [ 17472 ]
Fix Version/s JRuby 1.6.3 [ 17374 ]

People

  • Assignee:
    Unassigned
    Reporter:
    Charles Oliver Nutter
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: