weakref-based singleton class "attached" can blow up in certain unusual circumstances

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.1
  • Component/s: Core Classes/Modules
  • Labels:
    None

Description

Because the "attached" reference in a singleton class is now a weakref, we can occasionally run into cases where the singleton class exists but the object to which it is attached does not. This could cause problems if, for example, the singleton class is in use (perhaps in the middle of adding methods) at a point in time when the original object gets GCed. We need a better answer for when the attached object goes away but the singleton class is still alive, rather than waiting for NPEs to show up at some point in the future.

Activity

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

Punting issues from 1.1 RC2 to 1.1 final.

Show
Charles Oliver Nutter added a comment - Punting issues from 1.1 RC2 to 1.1 final.
Hide
Permalink
Charles Oliver Nutter added a comment -

I committed a fix in r6243 to make the "attached" reference a SoftReference...that should reduce the likelihood of this bug to nearly never. But it's not never, so just punting this to post 1.1 for additional examination.

Show
Charles Oliver Nutter added a comment - I committed a fix in r6243 to make the "attached" reference a SoftReference...that should reduce the likelihood of this bug to nearly never. But it's not never, so just punting this to post 1.1 for additional examination.
Hide
Permalink
Charles Oliver Nutter added a comment -

I'm satisfied this is unlikely enough to happen we can resolve the bug retroactively. Because it would require that the original object of the singleton class be dereferenced AND the softref collection fire at that time AND the original softref be dereferenced long enough to be reclaimed AND code still be executing against the singleton class without first referencing the original object...the probability is extremely low.

Show
Charles Oliver Nutter added a comment - I'm satisfied this is unlikely enough to happen we can resolve the bug retroactively. Because it would require that the original object of the singleton class be dereferenced AND the softref collection fire at that time AND the original softref be dereferenced long enough to be reclaimed AND code still be executing against the singleton class without first referencing the original object...the probability is extremely low.

People

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

Dates

  • Created:
    Updated:
    Resolved: