obmalloc: eliminate limit on pool size

[tim-one]

BPO	37211
Nosy	@tim-one
PRs	gh-81392: obmalloc: eliminate limit on pool size #13934

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tim-one'
closed_at = None
created_at = <Date 2019-06-10.00:36:19.909>
labels = ['interpreter-core', 'type-feature', '3.9']
title = 'obmalloc:  eliminate limit on pool size'
updated_at = <Date 2019-06-10.04:25:22.830>
user = 'https://github.com/tim-one'

bugs.python.org fields:

activity = <Date 2019-06-10.04:25:22.830>
actor = 'tim.peters'
assignee = 'tim.peters'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2019-06-10.00:36:19.909>
creator = 'tim.peters'
dependencies = []
files = []
hgrepos = []
issue_num = 37211
keywords = ['patch']
message_count = 1.0
messages = ['345097']
nosy_count = 1.0
nosy_names = ['tim.peters']
pr_nums = ['13934']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue37211'
versions = ['Python 3.9']

[tim-one]

On 64-bit Python, many object sizes essentially doubled over 32-bit Python, because Python objects are so heavy with pointers. More recently, forcing alignment to 16 bytes on 64-bit boxes boosted the memory requirements more modestly.

But obmalloc's 256 KiB arenas and 4 KiB pools haven't changed since obmalloc was first written, and its address_in_range() machinery cannot deal with pools bigger than that (they're segfault factories, because the machinery relies on that a pool is no larger than a system page).

obmalloc's fastest paths are those that stay within a pool. Whenever a pool boundary is hit, it necessarily gets slower, then slower still if an arena boundary is hit.

So I propose to:

• Remove the 4 KiB pool limit, by making address_in_range() page-based rather than pool-based. Pools should be able to span any power-of-2 number of pages. Then a pool for a given size class will be able to hold that many more times as many objects too, and so stay in the fastest paths more often.

• On 64-bit boxes, increase both POOL_SIZE and ARENA_SIZE.

[arhadthedev]

Closing after #13934 (comment).