Opened 4 years ago

Last modified 4 years ago

#10470 new bug

Allocating StablePtrs leads to GC slowdown even after they're freed

Reported by: bitonic Owned by: simonmar
Priority: normal Milestone:
Component: Runtime System Version: 7.10.1
Keywords: Cc: austin@…, slyfox@…, simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by bitonic)

If we allocate and then free a lot of StablePtrs the GC performance will be degrated for the rest of the execution.

I have attached a program that performs a GC-heavy task (foldr'ing a long list of Ints) before and after allocating and then freeing a million StablePtrs. After the StablePtrs are freed the task takes more than twice as long.

The reason for this is that stable_ptr_table in Stable.c is never resized, and is looped over for every GC pause.

Attachments (1)

stable-ptr-perf.hs (949 bytes) - added by bitonic 4 years ago.

Download all attachments as: .zip

Change History (4)

Changed 4 years ago by bitonic

Attachment: stable-ptr-perf.hs added

comment:1 Changed 4 years ago by bitonic

Description: modified (diff)

comment:2 Changed 4 years ago by ezyang

We can't fix this by trying to resize stable_ptr_table, however, because if we have a used stable pointer at location 0 and a used stable pointer at location n, we can't resize smaller than n. (We might be able to if we used a hash table, but that would hurt read performance.) So really we need to be more clever about how we traverse the static pointer table, maybe by linking live entries together or something more clever.

comment:3 Changed 4 years ago by bitonic

Yeah, I used "resize" in a fairly liberal way :).

One quick improvement would be to at least free empty tails, which wouldn't require any trick to maintain the existing indexes.

Note: See TracTickets for help on using tickets.