Skip to content

runtime: potential deadlock cycle caused by scavenge.lock #34047

Closed
@mknyszek

Description

@mknyszek

scavenge.lock in the runtime is in a lock cycle with several different locks, all because it may be acquired (and according to the runtime documentation, must!) after the heap lock is acquired.

While the chance for deadlock is incredibly low because it could only happen as the result of an errant stack growth (which takes the slow path), or a rare allocation in the timer code, or in a rare acquisition of sched.lock in ready(), this is nonetheless a regression in stability and we should remove the potential for this lock cycle.

I propose we simply move the scavenger-waking code out of gcPaceScavenger and into its own function which is then called after gcSetTriggerRatio where appropriate. There are only two callsites, so this should be no problem to do.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions