Memory Strategies – The Merits of (Un)safe
?
?
W, K, P / S, J, N Jump to previous / next timestamp
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus
Keyboard Navigation
Global Keys
[, < / ], > Jump to previous / next episodeW, K, P / S, J, N Jump to previous / next timestamp
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)
Menu toggling
q Quotes r References f Filter y Link c CreditsIn-Menu and Index Controls
a
w
s
s
d
h
j
k
l
←
↑
↓
↓
→
Esc Close menu / unfocus timestamp
Quotes and References Menus and Index
Enter Jump to timestampQuotes, References and Credits Menus
o Open URL (in new tab)Filter Menu
x, Space Toggle category and focus nextX, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus
Filter and Link Menus
z Toggle filter / linking modeCredits Menu
Enter Open URL (in new tab)⏫
Previous: 'Weathering Software Winter - Q&A'
⏫
0:00Opening Titles
0:00Opening Titles
0:00Opening Titles
0:43 : Welcome to the podcast on memory management and safety
0:43 : Welcome to the podcast on memory management and safety
0:43 : Welcome to the podcast on memory management and safety
2:07 : Introduce our moderator Allen Webster
2:07 : Introduce our moderator Allen Webster
2:07 : Introduce our moderator Allen Webster
2:50 : Introduce Evan Ovadia, creator of Vale,1 representing memory safety
2:50 : Introduce Evan Ovadia, creator of Vale,1 representing memory safety
2:50 : Introduce Evan Ovadia, creator of Vale,1 representing memory safety
3:13 : Introduce Ryan Fleury, promoting the merits of unsafety
3:13 : Introduce Ryan Fleury, promoting the merits of unsafety
3:13 : Introduce Ryan Fleury, promoting the merits of unsafety
3:24 : Introduce John Austin, founder of Pontoco,2 remaining more neutral
3:24 : Introduce John Austin, founder of Pontoco,2 remaining more neutral
3:24 : Introduce John Austin, founder of Pontoco,2 remaining more neutral
4:03 : Allen, take it away
4:03 : Allen, take it away
4:03 : Allen, take it away
4:15 : Introductions
4:15 : Introductions
4:15 : Introductions
4:40 : Introduction: Creator of Vale,3 work on games, servers, apps and languages
4:40 : Introduction: Creator of Vale,3 work on games, servers, apps and languages
4:40 : Introduction: Creator of Vale,3 work on games, servers, apps and languages
5:07 : Introduction: Founder and lead engineer of Pontoco,4 interested in the pragmatics of languages
5:07 : Introduction: Founder and lead engineer of Pontoco,4 interested in the pragmatics of languages
5:07 : Introduction: Founder and lead engineer of Pontoco,4 interested in the pragmatics of languages
6:03 : Introduction: Working on the debugger project at Epic Games, lifelong game maker, coming from the memory unsafe angle
6:03 : Introduction: Working on the debugger project at Epic Games, lifelong game maker, coming from the memory unsafe angle
6:03 : Introduction: Working on the debugger project at Epic Games, lifelong game maker, coming from the memory unsafe angle
6:52 : Introduction: Meta-interested in seeing programmers get better at having productive conversations on contentious topics
6:52 : Introduction: Meta-interested in seeing programmers get better at having productive conversations on contentious topics
6:52 : Introduction: Meta-interested in seeing programmers get better at having productive conversations on contentious topics
7:23 : Laying out the basics: 1) What is memory management?
7:23 : Laying out the basics: 1) What is memory management?
7:23 : Laying out the basics: 1) What is memory management?
7:50 : Memory management as the problem-space of organising memory re-use, grouping and arrangement
7:50 : Memory management as the problem-space of organising memory re-use, grouping and arrangement
7:50 : Memory management as the problem-space of organising memory re-use, grouping and arrangement
8:41 : Does that definition make sense to everyone else?
8:41 : Does that definition make sense to everyone else?
8:41 : Does that definition make sense to everyone else?
8:49 : That lines up pretty perfectly with my understanding
8:49 : That lines up pretty perfectly with my understanding
8:49 : That lines up pretty perfectly with my understanding
8:52 : Memory management considerations at the application-level
8:52 : Memory management considerations at the application-level
8:52 : Memory management considerations at the application-level
9:44 : So Ryan's definition is at the lowest level, with memory management taking on additional meaning in the context of different languages?
9:44 : So Ryan's definition is at the lowest level, with memory management taking on additional meaning in the context of different languages?
9:44 : So Ryan's definition is at the lowest level, with memory management taking on additional meaning in the context of different languages?
10:08 : Yeah
10:08 : Yeah
10:08 : Yeah
10:25 : Laying out the basics: 2) What is memory safety?
10:25 : Laying out the basics: 2) What is memory safety?
10:25 : Laying out the basics: 2) What is memory safety?
10:35 : Memory safety as ways to avoid undefined behaviour
10:35 : Memory safety as ways to avoid undefined behaviour
10:35 : Memory safety as ways to avoid undefined behaviour
11:44 : Does everyone understand that definition?
11:44 : Does everyone understand that definition?
11:44 : Does everyone understand that definition?
11:49 : Narrow down memory safety to the use-after-free and double-free area of undefined behaviour
11:49 : Narrow down memory safety to the use-after-free and double-free area of undefined behaviour
11:49 : Narrow down memory safety to the use-after-free and double-free area of undefined behaviour
12:22 : Include integer overflow in the scope of memory safety
12:22 : Include integer overflow in the scope of memory safety
12:22 : Include integer overflow in the scope of memory safety
12:37 : Summarise memory safety as ways to address bugs arising from memory-related undefined behaviours
12:37 : Summarise memory safety as ways to address bugs arising from memory-related undefined behaviours
12:37 : Summarise memory safety as ways to address bugs arising from memory-related undefined behaviours
13:06 : Associate memory safety with security
13:06 : Associate memory safety with security
13:06 : Associate memory safety with security
13:48 : Angles of memory safety: 1) Bounds-checking
13:48 : Angles of memory safety: 1) Bounds-checking
13:48 : Angles of memory safety: 1) Bounds-checking
14:16 : Angles of memory safety: 2) Privacy
14:16 : Angles of memory safety: 2) Privacy
14:16 : Angles of memory safety: 2) Privacy
14:47 : How important is memory safety?
14:47 : How important is memory safety?
14:47 : How important is memory safety?
15:25 : Memory safety importance is tied to the domain
15:25 : Memory safety importance is tied to the domain
15:25 : Memory safety importance is tied to the domain
16:30 : Memory safety as a proxy to other bugs
16:30 : Memory safety as a proxy to other bugs
16:30 : Memory safety as a proxy to other bugs
17:26 : What do you mean by "proxy"?
17:26 : What do you mean by "proxy"?
17:26 : What do you mean by "proxy"?
17:37 : Memory safety's solving of a subset of problems, all of which actually require robust logic
17:37 : Memory safety's solving of a subset of problems, all of which actually require robust logic
17:37 : Memory safety's solving of a subset of problems, all of which actually require robust logic
18:50 : Yeah, you can solve your memory problems but not necessarily your actual bugs?
18:50 : Yeah, you can solve your memory problems but not necessarily your actual bugs?
18:50 : Yeah, you can solve your memory problems but not necessarily your actual bugs?
19:00 : Even security exploits
19:00 : Even security exploits
19:00 : Even security exploits
19:08 : The difficulty of determining when we're merely shifting bugs
19:08 : The difficulty of determining when we're merely shifting bugs
19:08 : The difficulty of determining when we're merely shifting bugs
19:28 : Valuing memory safety for its ease of identifying and handling bugs
19:28 : Valuing memory safety for its ease of identifying and handling bugs
19:28 : Valuing memory safety for its ease of identifying and handling bugs
21:05 : Memory safety making problems less scary
21:05 : Memory safety making problems less scary
21:05 : Memory safety making problems less scary
21:31 : Memory safety depending on the domain
21:31 : Memory safety depending on the domain
21:31 : Memory safety depending on the domain
21:47 : Achieving memory safety: What is the borrow checker in Rust?
21:47 : Achieving memory safety: What is the borrow checker in Rust?
21:47 : Achieving memory safety: What is the borrow checker in Rust?
22:17 : Rust's borrow checker
22:17 : Rust's borrow checker
22:17 : Rust's borrow checker
24:18 : Do you consider the single-ownership aspect to be part of the borrow checker?
24:18 : Do you consider the single-ownership aspect to be part of the borrow checker?
24:18 : Do you consider the single-ownership aspect to be part of the borrow checker?
24:23 : In terms of ownership of the values themselves as opposed to the reference model?
24:23 : In terms of ownership of the values themselves as opposed to the reference model?
24:23 : In terms of ownership of the values themselves as opposed to the reference model?
24:29 : Yeah
24:29 : Yeah
24:29 : Yeah
24:30 : The ownership comes from the reference model
24:30 : The ownership comes from the reference model
24:30 : The ownership comes from the reference model
24:43 : I feel like they're intertwined
24:43 : I feel like they're intertwined
24:43 : I feel like they're intertwined
24:49 : Multi-ownership with pointers
24:49 : Multi-ownership with pointers
24:49 : Multi-ownership with pointers
25:06 : Single-ownership in Rust and C
25:06 : Single-ownership in Rust and C
25:06 : Single-ownership in Rust and C
26:04 : That's a very good point
26:04 : That's a very good point
26:04 : That's a very good point
26:09 : How much of this has runtime performance implications?
26:09 : How much of this has runtime performance implications?
26:09 : How much of this has runtime performance implications?
26:20 : Rust's borrow checker performance implications: 1) None, operating at compile-time
26:20 : Rust's borrow checker performance implications: 1) None, operating at compile-time
26:20 : Rust's borrow checker performance implications: 1) None, operating at compile-time
26:48 : Rust's borrow checker performance implications: 2) Its force to write your code differently
26:48 : Rust's borrow checker performance implications: 2) Its force to write your code differently
26:48 : Rust's borrow checker performance implications: 2) Its force to write your code differently
27:31 : So it's not like there's a bit that gets passed around to figure out who owns something?
27:31 : So it's not like there's a bit that gets passed around to figure out who owns something?
27:31 : So it's not like there's a bit that gets passed around to figure out who owns something?
27:40 : With single-ownership there is only one place that the data resides
27:40 : With single-ownership there is only one place that the data resides
27:40 : With single-ownership there is only one place that the data resides
28:04 : You can think of it like a bit that travels with the data, but at compile-time
28:04 : You can think of it like a bit that travels with the data, but at compile-time
28:04 : You can think of it like a bit that travels with the data, but at compile-time
28:21 : I feel like it's simpler than that, though
28:21 : I feel like it's simpler than that, though
28:21 : I feel like it's simpler than that, though
28:50 : Developing personal programming rules
28:50 : Developing personal programming rules
28:50 : Developing personal programming rules
30:00 : If you moved to C, to what degree would the lack of the borrow checker be a problem for you?
30:00 : If you moved to C, to what degree would the lack of the borrow checker be a problem for you?
30:00 : If you moved to C, to what degree would the lack of the borrow checker be a problem for you?
30:49 : Bringing a pure functional style from Rust to C, but leaving behind Rust's trouble with intrusive data structures
30:49 : Bringing a pure functional style from Rust to C, but leaving behind Rust's trouble with intrusive data structures
30:49 : Bringing a pure functional style from Rust to C, but leaving behind Rust's trouble with intrusive data structures
31:55 : I use intrusive structures in C a lot
31:55 : I use intrusive structures in C a lot
31:55 : I use intrusive structures in C a lot
32:04 : Can we define "intrusive structures"?
32:04 : Can we define "intrusive structures"?
32:04 : Can we define "intrusive structures"?
32:10 : Intrusive structure as a struct that points to a member of its own type
32:10 : Intrusive structure as a struct that points to a member of its own type
32:10 : Intrusive structure as a struct that points to a member of its own type
32:59 : Is that what "intrusive data structure" means to you, Evan
32:59 : Is that what "intrusive data structure" means to you, Evan
32:59 : Is that what "intrusive data structure" means to you, Evan
33:03 : Clarify that Rust can handle tree-shaped intrusive data structures
33:03 : Clarify that Rust can handle tree-shaped intrusive data structures
33:03 : Clarify that Rust can handle tree-shaped intrusive data structures
33:19 : Would a singly-linked list be a special-case of a tree and, therefore, work?
33:19 : Would a singly-linked list be a special-case of a tree and, therefore, work?
33:19 : Would a singly-linked list be a special-case of a tree and, therefore, work?
33:26 : Yes
33:26 : Yes
33:26 : Yes
33:27 : Why doesn't Rust's borrow checker like intrusive data structures?
33:27 : Why doesn't Rust's borrow checker like intrusive data structures?
33:27 : Why doesn't Rust's borrow checker like intrusive data structures?
33:32 : Understanding the borrow checker's trouble with doubly-linked lists due to them needing multiple mutable references to the same node
33:32 : Understanding the borrow checker's trouble with doubly-linked lists due to them needing multiple mutable references to the same node
33:32 : Understanding the borrow checker's trouble with doubly-linked lists due to them needing multiple mutable references to the same node
34:30 : So I couldn't remove a node because I couldn't fix up the nodes on either side?
34:30 : So I couldn't remove a node because I couldn't fix up the nodes on either side?
34:30 : So I couldn't remove a node because I couldn't fix up the nodes on either side?
34:37 : Yeah, you can reach the node through multiple immutable references, but can't modify anything
34:37 : Yeah, you can reach the node through multiple immutable references, but can't modify anything
34:37 : Yeah, you can reach the node through multiple immutable references, but can't modify anything
34:47 : Weird Rust libraries that allow doubly-linked lists
34:47 : Weird Rust libraries that allow doubly-linked lists
34:47 : Weird Rust libraries that allow doubly-linked lists
35:10 : The restrictive borrow checker's inspiration GhostCell5
35:10 : The restrictive borrow checker's inspiration GhostCell5
35:10 : The restrictive borrow checker's inspiration GhostCell5
35:57 : GhostCell6 is innovative, but only solving a problem that Rust itself creates
35:57 : GhostCell6 is innovative, but only solving a problem that Rust itself creates
35:57 : GhostCell6 is innovative, but only solving a problem that Rust itself creates
36:35 : Getting around the borrow checker as a national sport, e.g. Generational indices
36:35 : Getting around the borrow checker as a national sport, e.g. Generational indices
36:35 : Getting around the borrow checker as a national sport, e.g. Generational indices
37:15 : Graceful failure with generational handles in C
37:15 : Graceful failure with generational handles in C
37:15 : Graceful failure with generational handles in C
38:21 : Generational indices appearing in Windows XP
38:21 : Generational indices appearing in Windows XP
38:21 : Generational indices appearing in Windows XP
38:50 : I see
38:50 : I see
38:50 : I see
38:51 : Could we define generational indices?
38:51 : Could we define generational indices?
38:51 : Could we define generational indices?
38:59 : Generational index used to say "I am the nth spaceship to inhabit this slot in the array"
38:59 : Generational index used to say "I am the nth spaceship to inhabit this slot in the array"
38:59 : Generational index used to say "I am the nth spaceship to inhabit this slot in the array"
40:30 : Unilaterally disallow memory safety from games, for the delightful bugs when pointing to wrong entities
40:30 : Unilaterally disallow memory safety from games, for the delightful bugs when pointing to wrong entities
40:30 : Unilaterally disallow memory safety from games, for the delightful bugs when pointing to wrong entities
41:14 : Generational indices handle problems that memory safety cannot
41:14 : Generational indices handle problems that memory safety cannot
41:14 : Generational indices handle problems that memory safety cannot
42:01 : The borrow checker by default wouldn't let you access an old spaceship, would it?
42:01 : The borrow checker by default wouldn't let you access an old spaceship, would it?
42:01 : The borrow checker by default wouldn't let you access an old spaceship, would it?
42:13 : In C, using a fixed array…
42:13 : In C, using a fixed array…
42:13 : In C, using a fixed array…
42:20 : Right, if you're getting around the borrow checker by using a flat array of values
42:20 : Right, if you're getting around the borrow checker by using a flat array of values
42:20 : Right, if you're getting around the borrow checker by using a flat array of values
42:30 : With Ryan coming to and taking the performance hit of generational indices, unencumbered by Rust's borrow checker, it's not really a performance hit if it's the correct solution anyway
42:30 : With Ryan coming to and taking the performance hit of generational indices, unencumbered by Rust's borrow checker, it's not really a performance hit if it's the correct solution anyway
42:30 : With Ryan coming to and taking the performance hit of generational indices, unencumbered by Rust's borrow checker, it's not really a performance hit if it's the correct solution anyway
43:01 : The performance of generational indices
43:01 : The performance of generational indices
43:01 : The performance of generational indices
43:43 : Thoughts on forests of malloc() and free() – the programming of which Rust's memory safety features seem designed to aid – being wrong in the first place
43:43 : Thoughts on forests of malloc() and free() – the programming of which Rust's memory safety features seem designed to aid – being wrong in the first place
43:43 : Thoughts on forests of malloc() and free() – the programming of which Rust's memory safety features seem designed to aid – being wrong in the first place
45:03 : Layers of performance
45:03 : Layers of performance
45:03 : Layers of performance
46:26 : Plug 'Hard Mode Rust'7
46:26 : Plug 'Hard Mode Rust'7
46:26 : Plug 'Hard Mode Rust'7
47:06 : Using techniques from 'Hard Mode Rust'8 in C gives you stronger safety guarantees
47:06 : Using techniques from 'Hard Mode Rust'8 in C gives you stronger safety guarantees
47:06 : Using techniques from 'Hard Mode Rust'8 in C gives you stronger safety guarantees
47:58 : Custom allocators in 'Hard Mode Rust'9 – pool and temporary arenas – yielding memory safety
47:58 : Custom allocators in 'Hard Mode Rust'9 – pool and temporary arenas – yielding memory safety
47:58 : Custom allocators in 'Hard Mode Rust'9 – pool and temporary arenas – yielding memory safety
50:37 : Up-front allocation only being workable in certain domains
50:37 : Up-front allocation only being workable in certain domains
50:37 : Up-front allocation only being workable in certain domains
51:52 : How is a pool allocator implemented?
51:52 : How is a pool allocator implemented?
51:52 : How is a pool allocator implemented?
52:09 : Implementing a pool allocator
52:09 : Implementing a pool allocator
52:09 : Implementing a pool allocator
52:53 : Does that make sense to everyone else?
52:53 : Does that make sense to everyone else?
52:53 : Does that make sense to everyone else?
52:55 : Yeah
52:55 : Yeah
52:55 : Yeah
52:58 : Just making sure
52:58 : Just making sure
52:58 : Just making sure
53:02 : Seeing terms thrown around
53:02 : Seeing terms thrown around
53:02 : Seeing terms thrown around
53:14 : What does "arena allocator" mean?
53:14 : What does "arena allocator" mean?
53:14 : What does "arena allocator" mean?
53:22 : Implementing an arena (or bump) allocator
53:22 : Implementing an arena (or bump) allocator
53:22 : Implementing an arena (or bump) allocator
55:41 : Implementing a growable pool atop an arena
55:41 : Implementing a growable pool atop an arena
55:41 : Implementing a growable pool atop an arena
56:30 : Does everyone else follow all those ideas?
56:30 : Does everyone else follow all those ideas?
56:30 : Does everyone else follow all those ideas?
56:37 : Admire the virtual memory table
56:37 : Admire the virtual memory table
56:37 : Admire the virtual memory table
57:36 : Effectively reimplementing malloc()
57:36 : Effectively reimplementing malloc()
57:36 : Effectively reimplementing malloc()
58:14 : The general-purpose nature of malloc(), and speed of arenas
58:14 : The general-purpose nature of malloc(), and speed of arenas
58:14 : The general-purpose nature of malloc(), and speed of arenas
58:54 : Layering on free lists brings you closer to what malloc() does anyway
58:54 : Layering on free lists brings you closer to what malloc() does anyway
58:54 : Layering on free lists brings you closer to what malloc() does anyway
59:22 : Custom allocators tracking the size of allocations
59:22 : Custom allocators tracking the size of allocations
59:22 : Custom allocators tracking the size of allocations
59:53 : Liking custom allocators' tracking of allocation sizes
59:53 : Liking custom allocators' tracking of allocation sizes
59:53 : Liking custom allocators' tracking of allocation sizes
1:00:10 : Excitement for Vale,10 Zig11 and Odin12 natively supporting custom allocators
1:00:10 : Excitement for Vale,10 Zig11 and Odin12 natively supporting custom allocators
1:00:10 : Excitement for Vale,10 Zig11 and Odin12 natively supporting custom allocators
1:01:10 : How can a novel custom allocator be faster than malloc()
1:01:10 : How can a novel custom allocator be faster than malloc()
1:01:10 : How can a novel custom allocator be faster than malloc()
1:01:42 : More interested in "how can you make a faster general-purpose allocator?"
1:01:42 : More interested in "how can you make a faster general-purpose allocator?"
1:01:42 : More interested in "how can you make a faster general-purpose allocator?"
1:02:23 : malloc() can't know as much about the program as a custom allocator
1:02:23 : malloc() can't know as much about the program as a custom allocator
1:02:23 : malloc() can't know as much about the program as a custom allocator
1:02:30 : malloc() and free() prioritise simplicity and stability and, in so doing, sacrifice performance-helping information
1:02:30 : malloc() and free() prioritise simplicity and stability and, in so doing, sacrifice performance-helping information
1:02:30 : malloc() and free() prioritise simplicity and stability and, in so doing, sacrifice performance-helping information
1:03:06 : Making an arena the ground basis for composing memory allocators
1:03:06 : Making an arena the ground basis for composing memory allocators
1:03:06 : Making an arena the ground basis for composing memory allocators
1:06:22 : So you don't just want to have a custom allocator, but to have a different allocator from malloc() and free() as the base?
1:06:22 : So you don't just want to have a custom allocator, but to have a different allocator from malloc() and free() as the base?
1:06:22 : So you don't just want to have a custom allocator, but to have a different allocator from malloc() and free() as the base?
1:06:41 : Thoughts on malloc() and free() locking you into the most generic form of allocator
1:06:41 : Thoughts on malloc() and free() locking you into the most generic form of allocator
1:06:41 : Thoughts on malloc() and free() locking you into the most generic form of allocator
1:07:32 : As in a statically known size?
1:07:32 : As in a statically known size?
1:07:32 : As in a statically known size?
1:07:39 : Implementing a pool atop an arena
1:07:39 : Implementing a pool atop an arena
1:07:39 : Implementing a pool atop an arena
1:07:53 : Ergonomics of memory allocation
1:07:53 : Ergonomics of memory allocation
1:07:53 : Ergonomics of memory allocation
1:08:16 : Zig13 and Odin14 let you pass in an allocator
1:08:16 : Zig13 and Odin14 let you pass in an allocator
1:08:16 : Zig13 and Odin14 let you pass in an allocator
1:08:29 : Not wanting the ergonomics of passing in an allocator
1:08:29 : Not wanting the ergonomics of passing in an allocator
1:08:29 : Not wanting the ergonomics of passing in an allocator
1:08:46 : Are you saying, Ryan, that you can write code better if you know the specific allocator you're working with?
1:08:46 : Are you saying, Ryan, that you can write code better if you know the specific allocator you're working with?
1:08:46 : Are you saying, Ryan, that you can write code better if you know the specific allocator you're working with?
1:08:59 : Being okay with Odin's15 context system, and considering custom allocation atop arenas to be simpler
1:08:59 : Being okay with Odin's15 context system, and considering custom allocation atop arenas to be simpler
1:08:59 : Being okay with Odin's15 context system, and considering custom allocation atop arenas to be simpler
1:09:49 : The benefit of not having to call free() with arenas
1:09:49 : The benefit of not having to call free() with arenas
1:09:49 : The benefit of not having to call free() with arenas
1:10:07 : Evan, did you follow that train of thought?
1:10:07 : Evan, did you follow that train of thought?
1:10:07 : Evan, did you follow that train of thought?
1:10:16 : The trade-off of writing performant and simple code against a specific allocator, but having to remember to call free() with an arbitrary allocator
1:10:16 : The trade-off of writing performant and simple code against a specific allocator, but having to remember to call free() with an arbitrary allocator
1:10:16 : The trade-off of writing performant and simple code against a specific allocator, but having to remember to call free() with an arbitrary allocator
1:10:47 : Summarise Ryan's arena-based proposal in the context of library development
1:10:47 : Summarise Ryan's arena-based proposal in the context of library development
1:10:47 : Summarise Ryan's arena-based proposal in the context of library development
1:12:14 : Why arena-based allocation is easier, with a quote from Raymond Chen's article 'An amusing story about a practical use of the null garbage collector'16
1:12:14 : Why arena-based allocation is easier, with a quote from Raymond Chen's article 'An amusing story about a practical use of the null garbage collector'16
1:12:14 : Why arena-based allocation is easier, with a quote from Raymond Chen's article 'An amusing story about a practical use of the null garbage collector'16
1:15:19 : Finding arenas to be more special-purpose, for temporary allocation and non-temporary fixed data
1:15:19 : Finding arenas to be more special-purpose, for temporary allocation and non-temporary fixed data
1:15:19 : Finding arenas to be more special-purpose, for temporary allocation and non-temporary fixed data
1:16:10 : We have a contradiction
1:16:10 : We have a contradiction
1:16:10 : We have a contradiction
1:16:22 : Program lifetimes that may struggle with the arena model
1:16:22 : Program lifetimes that may struggle with the arena model
1:16:22 : Program lifetimes that may struggle with the arena model
1:17:56 : Arena lifetime example: Per-request arena for a web server
1:17:56 : Arena lifetime example: Per-request arena for a web server
1:17:56 : Arena lifetime example: Per-request arena for a web server
1:18:18 : Thoughts on an asynchronous task runner possibly not having the space to allocate a page per task
1:18:18 : Thoughts on an asynchronous task runner possibly not having the space to allocate a page per task
1:18:18 : Thoughts on an asynchronous task runner possibly not having the space to allocate a page per task
1:18:44 : For tasks smaller than a page, why not just use the stack?
1:18:44 : For tasks smaller than a page, why not just use the stack?
1:18:44 : For tasks smaller than a page, why not just use the stack?
1:19:04 : The stack might disappear in an asynchronous task runner if you go to sleep
1:19:04 : The stack might disappear in an asynchronous task runner if you go to sleep
1:19:04 : The stack might disappear in an asynchronous task runner if you go to sleep
1:19:28 : Implementing a pool that composes with an arena
1:19:28 : Implementing a pool that composes with an arena
1:19:28 : Implementing a pool that composes with an arena
1:22:40 : So your opinion is total, that all programs should be written with arenas?
1:22:40 : So your opinion is total, that all programs should be written with arenas?
1:22:40 : So your opinion is total, that all programs should be written with arenas?
1:22:57 : Benefits of arenas, e.g. Basil17
1:22:57 : Benefits of arenas, e.g. Basil17
1:22:57 : Benefits of arenas, e.g. Basil17
1:23:58 : That'd be the opposite of the ECS dream
1:23:58 : That'd be the opposite of the ECS dream
1:23:58 : That'd be the opposite of the ECS dream
1:24:03 : Maybe 50% of all dynamic allocation could use arenas
1:24:03 : Maybe 50% of all dynamic allocation could use arenas
1:24:03 : Maybe 50% of all dynamic allocation could use arenas
1:24:17 : The challenge of unravelling arenas
1:24:17 : The challenge of unravelling arenas
1:24:17 : The challenge of unravelling arenas
1:24:40 : What is that 50% difference between Ryan and Evan's perspectives?
1:24:40 : What is that 50% difference between Ryan and Evan's perspectives?
1:24:40 : What is that 50% difference between Ryan and Evan's perspectives?
1:25:07 : I think you could use the "compose atop arenas" system, just not a bump allocator, for everything
1:25:07 : I think you could use the "compose atop arenas" system, just not a bump allocator, for everything
1:25:07 : I think you could use the "compose atop arenas" system, just not a bump allocator, for everything
1:25:27 : Composing a pool atop an arena, providing the arena to, say, EntityAlloc() and EntityFree() functions
1:25:27 : Composing a pool atop an arena, providing the arena to, say, EntityAlloc() and EntityFree() functions
1:25:27 : Composing a pool atop an arena, providing the arena to, say, EntityAlloc() and EntityFree() functions
1:28:06 : Does that 50% difference remain, Evan?
1:28:06 : Does that 50% difference remain, Evan?
1:28:06 : Does that 50% difference remain, Evan?
1:28:20 : Clarifying question: Can this one function be used in situations where you're using either a bump or pool allocator?
1:28:20 : Clarifying question: Can this one function be used in situations where you're using either a bump or pool allocator?
1:28:20 : Clarifying question: Can this one function be used in situations where you're using either a bump or pool allocator?
1:28:32 : Which function?
1:28:32 : Which function?
1:28:32 : Which function?
1:28:35 : The one that's calling EntityAlloc() and EntityFree()
1:28:35 : The one that's calling EntityAlloc() and EntityFree()
1:28:35 : The one that's calling EntityAlloc() and EntityFree()
1:28:39 : Not either / or, the idea is that you pass both an arena and a pool's free list
1:28:39 : Not either / or, the idea is that you pass both an arena and a pool's free list
1:28:39 : Not either / or, the idea is that you pass both an arena and a pool's free list
1:29:23 : Counter example: …
1:29:23 : Counter example: …
1:29:23 : Counter example: …
1:29:33 : Pause to savour the disagreement
1:29:33 : Pause to savour the disagreement
1:29:33 : Pause to savour the disagreement
1:29:47 : Worry about accidental agreement
1:29:47 : Worry about accidental agreement
1:29:47 : Worry about accidental agreement
1:29:53 : Counter example: A program that accepts millions of arbitrary-length requests
1:29:53 : Counter example: A program that accepts millions of arbitrary-length requests
1:29:53 : Counter example: A program that accepts millions of arbitrary-length requests
1:31:01 : So this program is receiving potentially 10 million requests per second each with arbitrary-length input?
1:31:01 : So this program is receiving potentially 10 million requests per second each with arbitrary-length input?
1:31:01 : So this program is receiving potentially 10 million requests per second each with arbitrary-length input?
1:31:25 : Maybe it's generating arbitrary-length strings
1:31:25 : Maybe it's generating arbitrary-length strings
1:31:25 : Maybe it's generating arbitrary-length strings
1:31:45 : Lay out the one-request-per-second pitch
1:31:45 : Lay out the one-request-per-second pitch
1:31:45 : Lay out the one-request-per-second pitch
1:32:38 : So you've up-front allocated enough memory to fit one string of arbitrary length?
1:32:38 : So you've up-front allocated enough memory to fit one string of arbitrary length?
1:32:38 : So you've up-front allocated enough memory to fit one string of arbitrary length?
1:32:43 : Are you asking how arena-based allocation could deal with the sheer rate of arbitrary-length requests coming in?
1:32:43 : Are you asking how arena-based allocation could deal with the sheer rate of arbitrary-length requests coming in?
1:32:43 : Are you asking how arena-based allocation could deal with the sheer rate of arbitrary-length requests coming in?
1:33:01 : And, worst case, most users have small requests, with only the last 500,000 dishing up 1TB strings
1:33:01 : And, worst case, most users have small requests, with only the last 500,000 dishing up 1TB strings
1:33:01 : And, worst case, most users have small requests, with only the last 500,000 dishing up 1TB strings
1:33:19 : Well, 1TB is pretty nuts
1:33:19 : Well, 1TB is pretty nuts
1:33:19 : Well, 1TB is pretty nuts
1:33:28 : Yeah, let's say up to 1GB, but they're quickly coming in
1:33:28 : Yeah, let's say up to 1GB, but they're quickly coming in
1:33:28 : Yeah, let's say up to 1GB, but they're quickly coming in
1:33:33 : Server architecture may support spawning enough address spaces to solve this problem
1:33:33 : Server architecture may support spawning enough address spaces to solve this problem
1:33:33 : Server architecture may support spawning enough address spaces to solve this problem
1:33:51 : I don't think what's relevant to the question is the fact that physical memory will give out at some point
1:33:51 : I don't think what's relevant to the question is the fact that physical memory will give out at some point
1:33:51 : I don't think what's relevant to the question is the fact that physical memory will give out at some point
1:34:06 : If virtual allocating a bunch of space for each request, they will also run out
1:34:06 : If virtual allocating a bunch of space for each request, they will also run out
1:34:06 : If virtual allocating a bunch of space for each request, they will also run out
1:34:21 : Approaching John's counter example problem: Multiple thread pools for different-sized requests, rate-limiting them
1:34:21 : Approaching John's counter example problem: Multiple thread pools for different-sized requests, rate-limiting them
1:34:21 : Approaching John's counter example problem: Multiple thread pools for different-sized requests, rate-limiting them
1:36:17 : Agree with the code simplicity of arenas, but they have knock-on effects
1:36:17 : Agree with the code simplicity of arenas, but they have knock-on effects
1:36:17 : Agree with the code simplicity of arenas, but they have knock-on effects
1:37:10 : I'd be surprised if malloc() [sic] was going to be less performant
1:37:10 : I'd be surprised if malloc() [sic] was going to be less performant
1:37:10 : I'd be surprised if malloc() [sic] was going to be less performant
1:37:17 : The spec of that problem was: "a server that implements malloc()"
1:37:17 : The spec of that problem was: "a server that implements malloc()"
1:37:17 : The spec of that problem was: "a server that implements malloc()"
1:38:09 : Enjoy that summary of the hypothetical problem
1:38:09 : Enjoy that summary of the hypothetical problem
1:38:09 : Enjoy that summary of the hypothetical problem
1:38:30 : Summarise Ryan's case that arenas can cover many use cases, and John's case that lifetimes can be too chaotic for arenas
1:38:30 : Summarise Ryan's case that arenas can cover many use cases, and John's case that lifetimes can be too chaotic for arenas
1:38:30 : Summarise Ryan's case that arenas can cover many use cases, and John's case that lifetimes can be too chaotic for arenas
1:39:31 : What could make you all reevaluate your thinking on memory safety and arena-based allocation?
1:39:31 : What could make you all reevaluate your thinking on memory safety and arena-based allocation?
1:39:31 : What could make you all reevaluate your thinking on memory safety and arena-based allocation?
1:40:35 : Memory safety reevaluation: Scepticism that the borrow-checker is universally useful
1:40:35 : Memory safety reevaluation: Scepticism that the borrow-checker is universally useful
1:40:35 : Memory safety reevaluation: Scepticism that the borrow-checker is universally useful
1:41:23 : Arena reevaluation: Enjoying the concept of an output arena
1:41:23 : Arena reevaluation: Enjoying the concept of an output arena
1:41:23 : Arena reevaluation: Enjoying the concept of an output arena
1:42:16 : That's great. John?
1:42:16 : That's great. John?
1:42:16 : That's great. John?
1:42:21 : Memory safety reevaluation: Improved ergonomics over Rust
1:42:21 : Memory safety reevaluation: Improved ergonomics over Rust
1:42:21 : Memory safety reevaluation: Improved ergonomics over Rust
1:44:26 : It sounds like you see benefits to other styles, but the ergonomics are too costly?
1:44:26 : It sounds like you see benefits to other styles, but the ergonomics are too costly?
1:44:26 : It sounds like you see benefits to other styles, but the ergonomics are too costly?
1:44:44 : I need to write lots of code that's fast enough for the use-case
1:44:44 : I need to write lots of code that's fast enough for the use-case
1:44:44 : I need to write lots of code that's fast enough for the use-case
1:45:12 : That makes perfect sense
1:45:12 : That makes perfect sense
1:45:12 : That makes perfect sense
1:45:17 : Is Rust's improved development speed attributable to the borrow checker or the type system?
1:45:17 : Is Rust's improved development speed attributable to the borrow checker or the type system?
1:45:17 : Is Rust's improved development speed attributable to the borrow checker or the type system?
1:45:41 : Love Rust for smart API decisions, type system and sensibleness
1:45:41 : Love Rust for smart API decisions, type system and sensibleness
1:45:41 : Love Rust for smart API decisions, type system and sensibleness
1:46:25 : Ryan?
1:46:25 : Ryan?
1:46:25 : Ryan?
1:46:34 : Memory safety reevaluation: Welcoming compile-time checks if implemented more simply
1:46:34 : Memory safety reevaluation: Welcoming compile-time checks if implemented more simply
1:46:34 : Memory safety reevaluation: Welcoming compile-time checks if implemented more simply
1:50:11 : Note of hope: 1) Languages selectively learning from Rust, e.g. Val18 with its mutable value semantics model and cloning
1:50:11 : Note of hope: 1) Languages selectively learning from Rust, e.g. Val18 with its mutable value semantics model and cloning
1:50:11 : Note of hope: 1) Languages selectively learning from Rust, e.g. Val18 with its mutable value semantics model and cloning
1:51:02 : Note of hope: 2) Composability of memory safety features, e.g. Vale's19 region borrow checker, and Cone20 as Rust with reference counting and garbage collection
1:51:02 : Note of hope: 2) Composability of memory safety features, e.g. Vale's19 region borrow checker, and Cone20 as Rust with reference counting and garbage collection
1:51:02 : Note of hope: 2) Composability of memory safety features, e.g. Vale's19 region borrow checker, and Cone20 as Rust with reference counting and garbage collection
1:51:46 : Yearn for simplification to everything but the language, e.g. file formats, debug info
1:51:46 : Yearn for simplification to everything but the language, e.g. file formats, debug info
1:51:46 : Yearn for simplification to everything but the language, e.g. file formats, debug info
1:52:54 : Love Rust's tooling
1:52:54 : Love Rust's tooling
1:52:54 : Love Rust's tooling
1:53:03 : Time for plugs
1:53:03 : Time for plugs
1:53:03 : Time for plugs
1:53:23 : Plug Vale21
1:53:23 : Plug Vale21
1:53:23 : Plug Vale21
1:53:29 : Plug personal22 and Pontoco23 websites
1:53:29 : Plug personal22 and Pontoco23 websites
1:53:29 : Plug personal22 and Pontoco23 websites
1:53:45 : Plug blog24 and the article 'Untangling Lifetimes: The Arena Allocator'25
1:53:45 : Plug blog24 and the article 'Untangling Lifetimes: The Arena Allocator'25
1:53:45 : Plug blog24 and the article 'Untangling Lifetimes: The Arena Allocator'25
1:54:01 : Thanks, everybody and Abner
1:54:01 : Thanks, everybody and Abner
1:54:01 : Thanks, everybody and Abner
1:54:05Closing Titles
1:54:05Closing Titles
1:54:05Closing Titles
⏬
Next: 'Spall'
⏬