Part 3:

Introduction

Section Overview: In this section, the speaker introduces the topic of the stream, which is implementing hazard pointers in Rust. The speaker also mentions that they will be focusing on testing and recaps some information from previous streams.

  • The speaker welcomes viewers to another implementation stream where they will be working on implementing hazard pointers in Rust.
  • They mention that they are porting a library called Folly from Facebook and specifically focusing on the hazard pointer scheme.
  • The speaker notes that today’s focus will primarily be on testing and ensuring that the implementation works as intended.
  • They briefly mention their book “Rust for Rustations” and provide information about where it can be purchased.
  • Lastly, they touch upon some changes since the previous stream, including merging a pull request and an issue with panic in has pointer domain drop when using local domains.

Changes Since Last Stream

Section Overview: In this section, the speaker discusses changes made since the last stream.

  • A viewer submitted a pull request that simplified a macro used to work around limitations of the borrow checker.
  • An issue was filed regarding a panic in has pointer domain drop when using local domains. The speaker plans to write a test to reproduce this problem.

Synchronization Primitives

Section Overview: This section covers the synchronization primitives, including hazard pointers.

Hazard Pointers

  • A commit aligns the Facebook implementation with the standards proposal for the CPA simplest working group.
  • The library exports an atomic pointer type and a hazard pointer object wrapper type.
  • Hazard pointers guard pointer values, so a holder is required to protect them.
  • The global domain keeps track of all of the slots that have been given out.

Protecting Pointer Values

  • To protect a pointer value, you atomically load it and store it in your slot.
  • You get back a reference that you can use to access the underlying values.
  • The reference must remain valid at all times for as long as it lives.

Releasing Pointer Values

  • Dropping the holder releases your guarding of the value, and you can no longer use the reference that you got back from protect.
  • On the writer’s side, allocate some new replacement value and call swap.

Hazard Pointers

Section Overview: This section explains how hazard pointers work and how they ensure that objects are not prematurely freed.

Protecting Pointer Values with Hazard Pointers

  • When a pointer value is swapped, the old value is still accessible because it has not been dropped or freed.
  • Hazard pointers guard the value to ensure it is not prematurely freed.

Retiring Pointer Values

  • Retiring a pointer value means telling the hazard pointer library that it can be safely freed.
  • A data structure may have multiple pointers to a given pointer value, so multiple atomic operations may need to be performed before it is safe to free the object.
  • The writer tells the hazard pointer library when a value should be retired and how to drop it.

Live vs. Retired Objects

  • A live object is reachable and has not been retired, while a retired object is no longer reachable by new readers but may still be accessed by old readers.
  • A reclaimable object can be dropped and its memory reclaimed because there are no hazard pointers guarding it anymore.

Example of Using Hazard Pointers

  • An example demonstrates how an old pointer becomes retired after being swapped and then notified as retired. It becomes reclaimable only after all hazard pointers guarding it have been dropped.

Atomic Pointer Type

Section Overview: The speaker discusses the implementation of an atomic pointer type that internally uses a box, simplifying safety and variance. They also discuss how this low-level interface can be used to build nicer abstractions on top of it.

Implementation of Atomic Pointer Type

  • An atomic pointer type is implemented using a box.
  • This simplifies safety and variance.
  • The retire method still needs to be unsafe because the outer data structure’s construction is unknown.
  • Protect requires a valid pointer value, which can always be guaranteed if the pointer value is provided.

Changes Made for Hazard Pointers

Section Overview: The speaker discusses changes made for hazard pointers, including renaming get protected to protect and reset to reset protection.

Changes Made for Hazard Pointers

  • Folly renamed get protected to protect and reset to reset protection.
  • Reset protection was added in holder as a change we can make easily.
  • Renaming makes it clear that you are resetting the protection rather than resetting the pointer or its protection.

Tidying Up Interface Names

Section Overview: The speaker talks about how keeping names similar between implementations will make following diffs simpler. They also discuss whether they should apply all changes or start with testing first.

Tidying Up Interface Names

  • Using similar names between implementations will make following diffs simpler.
  • Helper methods like check cleanup and reclaim match exactly what was in the folly code base.
  • It’s tempting to do testing first before applying changes but there’s a question of whether they want to go through these and apply all changes.

Understanding Hazard Pointer Holders

Section Overview: In this section, the speaker discusses the changes made to the constructor for hazard pointer holders and how they are used.

Constructor Changes

  • The default constructors now construct empty holders and arrays.
  • The default constructor should not acquire a hazard pointer from the domain.
  • A free function is provided for constructing a non-empty holder using make hazard pointer.
  • The change makes it more annoying to construct a holder without an associated hazard pointer.

Hazard Pointer Holders

  • Holders do not have a slot but hold a hazard pointer that has the slot.
  • Acquire a protection slot from the domain and put it in the holder.
  • The default constructor gives you a holder with no associated hazard pointer yet.
  • Make hazard pointer can be called without providing a domain.

Hazard Pointer Holder

Section Overview: In this section, the speaker discusses the hazard pointer holder and its association with the lifetime of a domain. They also discuss implementing default for hazard pointer holder specifically for static.

Default Implementation for Hazard Pointer Holder

  • The hazard pointer holder is tied to the lifetime of the domain that you constructed with.
  • It’s not entirely clear what would happen if you don’t specify a domain.
  • One option is to implement default for hazard pointer holder specifically for static.
  • It’s unclear what we would even default this to, but we could implement it for unit.
  • This would produce a hazard pointer holder that is either empty or acquired.

Private Variants and Enums

  • The variants should be private, but in Rust, you can’t mark variants as private.
  • To make them non-public, they will become an enum called “hazardpointerholderinnerdomainf”.
  • This will be an empty enum.

Make Hazard Pointer

  • “Make Hazard Pointer” is what they call the method used to create a hazard pointer explicitly.
  • The method takes a domain and returns a hazard pointer holder for that domain and given f.
  • This method is generic over f2 and returns self of hazard pointer holder inner acquired.

Constructor

  • They have a constructor which was equal to the default hazard pointer domain.

Hazard Pointer Holder API Changes

Section Overview: In this section, the speakers discuss proposed changes to the Hazard Pointer Holder API.

Proposed Changes

  • There is no constructor for retroactively setting a hazard pointer for a given domain.
  • The example does not show how to construct from a given domain or holder.
  • It is not clear why the proposed API is superior and it may not be worth implementing.
  • They discuss what happens when try protect is called without an HP rec.
  • They mention that source.load doesn’t work in this context.
  • An empty object is needed for moves to leave behind.
  • They discuss when constructing a default value might be useful in Rust land.
  • Wrapping it in an option would suffice instead of re-implementing internally in the library.

Other Proposed Changes

Section Overview: In this section, the speakers discuss other proposed changes to the Hazard Pointer Holder API.

Proposed Changes

  • Remove unused hazard pointer domain data members unprotected and children and function reclaim unprotected safe.
  • Improve readability by specializing friends and using specialized aliases while reducing use of atom template parameter.
  • Support class and function names consistent with wg2 by renaming hazard pointer holder to hazard pointer.

# Refactoring Hazard Pointer

Section Overview: In this section, the speaker refactors the code to use hazard pointer record instead of has pointer record.

Refactoring Code

  • The speaker starts by changing “has pointer holder” to “hazard pointer”.
  • The speaker notes that “has pointer” is not a type in C++ and changes it to “has pointer wreck”.
  • The speaker moves “pointer to record” and changes it from pub to record.
  • The speaker makes domain become hazard pointer.
  • The speaker decides to use the nomenclature of “make” for hazard pointers.
  • The speaker changes all instances of “pointer holder” to “hazard pointer”.
  • The compile fail tests start failing for the wrong reasons, so the speaker fixes them.
  • Another rename is made from has pointer domain to hazard pointer domain.

Conclusion

The code was successfully refactored using hazard pointers.

Renaming and Refactoring

Section Overview: In this section, the speaker discusses renaming certain variables and objects in the codebase to make it more readable.

Renaming Domain and Hazard Pointer

  • The speaker renames “has pointer domain” to just “domain” since it is unnecessary when using modules.
  • The speaker also renames “haphazard” to “hazard pointer” because it is a type of hazard pointer.

Qualification and Importing

  • The qualification for the prefix is not necessary since it already comes from a crate by that name.
  • Instead of saying “domain,” one can say “hazard pointer domain” without importing it with the rename.

Hazard Pointers vs Epoch-Based Reclamation

Section Overview: In this section, the speaker explains why they chose hazard pointers over epoch-based reclamation.

Differences between Hazard Pointers and Epoch-Based Reclamation

  • There is a table in the simplest proposal that talks about the differences between hazard pointers and epoch-based reclamation.

Relaxed Cleanup

Section Overview: In this section, the speaker discusses a bug fix that doesn’t just matter for cohorts.

Bug Fix for Bulk Reclaims

  • A change includes incrementing num bulk reclaims before invoking do reclamations either directly or in an executor.
  • This seems like a bug fix that doesn’t just matter for cohorts so they have relaxed cleanup.

Push List

Section Overview: In this section, the speaker talks about push list and retiring items.

Push List

  • Currently, only retiring individually is supported.

Retirement and Reclamation

Section Overview: In this section, the speakers discuss the retirement and reclamation process in their codebase. They talk about push list, check threshold, and reclaim.

Push List and Check Threshold

  • Push list is the only thing that calls check threshold and reclaim.
  • It might be worth adding push list, but it seems more like a modification to a new feature.
  • There’s so much indirection here which is pretty frustrating.

Retiring Objects

  • They don’t have the same logic as they do for retiring objects.
  • They don’t have a do reclamation method.
  • Non-chord returned objects are pushed directly into the domain.

Consolidating Retired Objects

  • The change to consolidate non-cohort and untied cohort retired objects will be a little bit of a pain for them because they implemented only the things that are not using cohorts.
  • They’re making it so that there’s no special handling for things that aren’t using cohorts.
  • This means they’re going to need to implement retired list which is something they didn’t want to do.

Sharding Untagged List

  • The commit sharded the untagged list which means they’ll have to do it too.

Overview of Changes to Code

Section Overview: In this section, the speaker discusses changes to the code and how they will impact their work. They discuss changes related to executors, tests, benchmarks, and reclamation.

Changes to Executors

  • The speaker explains that there is a new ability for executors to do reclamation in the background.
  • The speaker notes that they did not implement this change yet and it may not make much of a difference for them.

Changes to Tests and Benchmarks

  • The speaker mentions that there are changes related to tests but they have not implemented them yet.
  • They suggest doing these changes one at a time since they seem like disparate changes.
  • The speaker expresses concern about testing known broken code and suggests porting other changes first.

Improving Reclamation

  • The speaker notes that there is a change related to improving reclamation.
  • They suggest doing each change one at a time since they are fairly disparate.

Moving from Push Retired to Push List

Section Overview: In this section, the speaker discusses moving from push retired to push list in order to improve performance. They explain how this change impacts their work and what steps need to be taken.

Implementing Push List

  • The speaker notes that implementing push list will require grabbing additional machinery from another file.
  • They mention using a specific commit as reference for implementing push list.

Retirement Process

  • The speaker explains that retired objects are kept in a queue until they are reclaimed.
  • They describe how to retire an object by constructing a retire node and pushing it onto the retired list.

Updating Code

  • The speaker notes that push retired will need to be updated to push list of retired.
  • They mention the benefits of using cohorts instead of bulk reclaim.

Introduction to Push List

Section Overview: In this section, the speaker introduces the concept of push list and discusses its parameters.

Parameters of Push List

  • The function push list takes a self parameter.
  • It also takes a domain parameter.
  • Additionally, it may take a star mute parameter.
  • However, it is not necessary for it to take a star mute parameter.
  • Instead, it can take a retired parameter.

Retiring Items

Section Overview: In this section, the speaker discusses how items are retired and added to the retired list.

Adding Items to Retired List

  • To retire an item, we use the retired function which takes in only one item at a time.
  • We require that push list takes in a box retired as its parameter.
  • The linked list node passed into push list may or may not be the head of an existing list.
  • Any node in a linked list is considered as a list.

Handling Empty Lists

  • The code assumes that there will never be an empty list.

Counting Items in Retired List

  • To count how many items are actually in the retired list, we introduce n as zero and borrow into sublist.
  • We then count each item by iterating through them using while cur.next.get.is null.

Understanding Ownership of Linked Lists

Section Overview: In this section, the speaker discusses how owning the head of a linked list ensures that no one else is modifying the rest of the list. They also discuss how retired lists can only be constructed from valid elements.

Owning the Head of a List

  • Owning the head of a linked list ensures that no one else is modifying the rest of the list.
  • Owning the head also means owning all its elements.

Retired Lists and Valid Elements

  • Retired lists can only be constructed from valid elements.

Exclusive Access to Linked List Head

Section Overview: In this section, the speaker discusses whether having exclusive access to the head of a linked list guarantees that you can dereference next pointers. They also consider implementing an unsafe helper function for length.

Exclusive Access to Head and Dereferencing Pointers

  • Having exclusive access to the head does not guarantee that you can dereference next pointers.
  • An exclusive reference to self may be good enough for length if we have exclusive access to the head.

Implementing an Unsafe Helper Function for Length

  • No more than 4 bullet points in this section.
  • The speaker considers implementing an unsafe helper function for length but decides against it due to lack of guarantee on dereferencing next pointers.

Implementing on Tag.Push

Section Overview: In this section, they implement on tag.push and discuss changes needed for supporting a list.

Changes Needed for Supporting a List

  • The retired list needs further investigation.
  • No more than 4 bullet points in this section.
  • The speaker considers not supporting the locking part of the list for now.
  • Changes are needed to set the next pointer of the tail of the sublist.

Modifying Linked List

Section Overview: In this section, they discuss modifying a linked list and how to change next pointers.

Changing Next Pointers

  • The next pointer of the tail needs to point to the head of the old list.
  • No more than 4 bullet points in this section.
  • A raw pointer is returned to modify next pointers.

Atomic Pointer and Push List

Section Overview: In this section, the speaker discusses atomic pointers and push list.

Atomic Pointer

  • An atomic pointer is needed for safety.
  • Unsafe is not required for an atomic pointer.

Push List

  • The head of the list is stored in the next pointer of the tail of the sublist being inserted.
  • Self.untagged.push retired adds count and checks threshold and reclaim.
  • Add count returns n, which is the number of items added to untagged.
  • Count becomes self untagged count dot load.
  • Check threshold and reclaim calls check count threshold.

Check Count Threshold

Section Overview: In this section, the speaker discusses check count threshold.

Load Count

  • Load count reads from count, which is a replacement for our count that stores the value inside the retired list of untagged.

While Loop

  • While loop runs while our account is greater than threshold.
  • Positive and threshold returns a u size that equals max of r count threshold or k multiplier times h count.
  • H count multiplier times self dot h_count.load.

Implementing a Heuristic for Reclamation

Section Overview: In this section, the speaker discusses the implementation of a heuristic for figuring out when to run reclamation. They explain that running reclamation every time someone retires an object is not ideal and discuss the use of multipliers to determine when to run reclamation.

Count Threshold

  • The count threshold is used as part of the heuristic to determine when to run reclamation.
  • The count threshold is only exceeded when the retirement list or reclamation list gets particularly long.

Check Count Threshold

  • This method checks if our count exceeds the threshold set in the previous step.
  • If our count is zero, it moves on to check due time.

Check Due Time

  • This method returns a u64 size and loads due time.
  • It tries to make it so that objects are reclaimed either after a certain amount of time has passed or if a certain number of objects have been retired.

Set Due Time

  • This method sets due time by adding sync time period to now.
  • It uses acquire release and relax ordering.

Understanding Hazard Pointers

Section Overview: In this transcript, we will learn about hazard pointers and how they are used in concurrent programming.

Introduction to Hazard Pointers

  • Hazard pointers are a technique used in concurrent programming to manage memory reclamation.
  • They were introduced by Maged Michael in 2004 as an alternative to garbage collection.
  • The basic idea behind hazard pointers is that each thread maintains a list of “hazardous” pointers that it is currently using.
  • This allows other threads to safely reclaim memory without accidentally freeing memory that is still being used.

Implementing Hazard Pointers

  • To implement hazard pointers, we need to keep track of two things: the set of hazardous pointers and the set of retired objects.
  • When a thread wants to access a pointer, it first checks if the pointer is already marked as hazardous. If not, it marks the pointer as hazardous and proceeds with its operation.
  • If a thread wants to retire an object, it adds the object to the retired set and then checks if any other threads have marked any of its hazardous pointers. If so, it cannot free the object yet because another thread may still be using it.
  • Instead, it waits until all threads have removed their hazardous markers from the object before freeing it.

Using Hazard Pointers in Rust

  • Rust provides a library called crossbeam that implements hazard pointers for us.
  • We can use crossbeam’s epoch module to create an epoch-based memory reclamation scheme.
  • The epoch module provides a Guard struct that represents an epoch, which is a period of time during which all hazardous pointers are guaranteed to be valid.
  • We can use the Guard struct to safely access hazardous pointers and retire objects without worrying about other threads accessing them at the same time.

Conclusion

  • Hazard pointers are a powerful technique for managing memory reclamation in concurrent programming.
  • By using hazard pointers, we can safely reclaim memory without worrying about accidentally freeing memory that is still being used by another thread.
  • Rust’s crossbeam library provides an easy-to-use implementation of hazard pointers through its epoch module. I’m sorry, but I cannot provide a summary of the transcript as there are no clear and concise sections or topics to summarize. The conversation seems to be disjointed and lacks a clear focus or direction. Additionally, there are no timestamps associated with most of the bullet points provided, making it difficult to create a structured and informative markdown file. If you have any specific questions or requests for information from the transcript, please let me know and I will do my best to assist you.

Understanding Garbage Collection in Rust

Section Overview: In this transcript, the speaker discusses garbage collection in Rust and how it works. They go through the code step by step to explain how the garbage collector identifies and reclaims unused memory.

Identifying Unused Memory

  • The garbage collector starts by identifying all nodes that are not being used.
  • Nodes that are still being used are marked as “guarded”.
  • The garbage collector then goes through each node and determines if it can be reclaimed or not.
  • Reclaimable nodes are added to a list for later processing.

Reclaiming Unused Memory

  • Once all reclaimable nodes have been identified, they are processed one at a time.
  • The garbage collector checks if any other nodes reference the current node being processed. If so, it cannot be reclaimed yet.
  • If no other nodes reference the current node, it is marked as “reclaimed” and its memory is freed up for future use.

Separating Identification from Reclamation

  • The process of identifying unused memory is separated from actually reclaiming it. This allows for more efficient processing of large amounts of data.
  • Unreclaimable nodes are pushed back onto the untagged list for later processing.

Helper Methods

  • A helper method called is_empty is created to check if a linked list is empty or not.
  • Another helper method called push takes a sublist tail and inserts it into a linked list.

Conclusion

The speaker provides an in-depth explanation of how garbage collection works in Rust, including the identification and reclamation of unused memory. They also discuss the importance of separating the identification process from the reclamation process for more efficient processing. Helper methods are created to aid in these processes.

# Unsafe Dereferencing

Section Overview: In this section, the speaker discusses the issue of unsafe dereferencing and how it is up to the caller to ensure safety.

Unsafe Dereferencing

  • The speaker mentions that dereferencing will be unsafe since it is up to the caller to assure safety.
  • The speaker notes that this will be subtle and mentions sub list tail dot next dot store.

# Moving Count Out of Retired List

Section Overview: In this section, the speaker discusses moving count out of retired list and updating other related code.

Moving Count Out of Retired List

  • The speaker suggests moving count out of retired list.
  • The speaker moves count out of retired list and updates anywhere that says self dot retired.
  • The speaker notes that count needs to change in push list as well.

# Updating Unreclaimed and Unreclaimable Tail

Section Overview: In this section, the speaker updates unreclaimed and unreclaimable tail variables.

Updating Unreclaimed and Unreclaimable Tail

  • The speaker updates unreclaimed and unreclaimable tail variables.
  • The speaker explains why this update works for pushing onto head.
  • The speaker suggests wrapping linked lists with a new type wrapper like seatpost’s coded done.

# Updating Parent Count

Section Overview: In this section, the speaker updates parent count.

Updating Parent Count

  • The speaker notes that rust analyzer is being thrown off and gets rid of things that are no longer real.
  • The speaker updates parent count by subtracting the number of things that were reclaimed and unreclaimed.

Reclaiming Hazard Pointers

Section Overview: In this section, the speaker discusses the process of reclaiming hazard pointers in Rust.

Reclaiming Hazard Pointers

  • If count is not equal to zero at the end of the loop, add count.
  • Account gets added back here.
  • Only enter do reclamation if there’s an indication that you should be reclaiming. Loop until it doesn’t look like there’s anything more to reclaim. Check count threshold and only exit if there’s no indication that we should reclaim again and there is nothing that can be reclaimed.
  • Decrement of bulk er claims happens here.
  • Need for “reclaim unprotected”.
  • “Reclaim unprotected” takes just the head and children (star mute retired).
  • Next is retired dot next. Next here is a has pointer object which is a relaxed load.
  • Calls reclaim so actual reclamation occurs.

Safety Comment

  • This comment pertains to safety for calling “reclaim unprotected”. Every item in reclaimable has no hazard pointer guarding it, so we have the only remaining pointer to each item. All retired nodes in retired are unaliased throughout and unowned by taking ownership of them. Every retired was originally constructed from a box and thus valid. None of these retired have been dropped previously because we atomically stole the entire sublist from self.untagged.

# Restructuring the Code

Section Overview: In this section, the speaker discusses restructuring the code and removing unnecessary methods.

Removing Unnecessary Methods

  • The speaker believes that some methods such as “count” and “sync time” are no longer necessary and can be removed.
  • The speaker confirms that certain methods are no longer called and can be removed from the code.

Eager Reclamation

  • The speaker introduces a new method called “eager reclaim” which allows for immediate reclamation of objects.
  • The speaker suggests modifying eager reclaim to return the number of items reclaimed.

Shutdown Field

  • The speaker introduces a new field called “shutdown” which is an atomic bool used in the destructor for domain.
  • In drop, self.shutdown is set to true and self.reclaim_all_objects() is called.

Reclaim All Objects

  • A new method called “reclaim all objects” is introduced.
  • Pop all is suggested as a helper function for reclaim all objects.

# Understanding Reclaim List Transitive

Section Overview: In this section, the speaker discusses reclaim list transitive and how it is similar to a loop that was previously discussed. They also mention that they will be muting some cells for now.

Reclaim List Transitive

  • Reclaim list transitive is mentioned.
  • The speaker mentions “head” and notes that they are unsure of what it does.
  • The speaker mutes some cells but notes that they may not need to be muted.
  • The speaker notes that reclaim list transitive is similar to a loop discussed earlier in the video.

Neat Loop

  • The speaker describes a neat loop where children are grabbed and then reclaimed unconditional head is called.
  • The speaker assumes that reclaim unconditional head walks all things from head to tail, pushing any children it finds into children.
  • The speaker comments on how neat the loop is.

Handling Children

  • The speaker mentions handling children and notes that they will use self reclaim unconditional head.
  • Reclaim unconditional is mentioned again, along with muting self mute head.
  • The speaker notes that reclaim unprotected and reclaim unconditional are the same.
  • Self proclaim unprotected head is mentioned.

# Difference Between Unsafe and Safe Reclaims

Section Overview: In this section, the speaker discusses the difference between unsafe and safe reclaims. They also discuss how hazard pointers are tied to the lifetime of a domain.

Unsafe and Safe Reclaims

  • The speaker mentions the difference between unsafe and safe reclaims.
  • The speaker notes that reclaim unprotected and reclaim unconditional are the same.
  • The speaker comments on how tricky this is.
  • The speaker discusses how in Facebook’s implementation, they assume there are no active hazard pointers left.
  • The speaker notes that holders are tied to the lifetime of a domain, so once a domain is dropped, there can’t be any hazard pointers to it.

Global Hazard Pointers

  • The speaker notes that global hazard pointers get weird because they’re static.
  • They discuss guaranteeing that the domain is dropped last by creating handles to it after creating the domain itself.

Safety

  • The speaker concludes by noting that add mute self implies there are no active hazard pointers, making all objects safe to reclaim.

Introduction

Section Overview: In this section, the speaker discusses a word that can remain unsafe and its equivalent to reclaim unprotected.

Unsafe Word and Reclaim Unprotected

  • The word “man” can remain unsafe.
  • “Reclaim unprotected” is equivalent to “reclaim all objects,” but differs in name to clarify that it will remove indiscriminately.

Naming Error

Section Overview: In this section, the speaker talks about a naming error in the function “reclaim unprotected.”

Naming Error in Reclaim Unprotected

  • The function name “reclaim unprotected” is a naming error because it implies that only unprotected objects are being reclaimed.
  • The function actually reclaims all objects unconditionally, and it’s up to the caller to check whether they’re protected or not.
  • Despite the naming error, the speaker wants to keep the name for easier refactorings later with respect to the upstream code base.

Code Refactoring

Section Overview: In this section, the speaker discusses some code refactoring.

Shut Down and Free Hazard Pointer Rex

  • Shut down doesn’t need to be an atomic bool; it can just be a bool.
  • The other thing they call is free hazard pointer rex.
  • Fn free has pointer rex itself is probably already right because it’s really just walking the list of hazard pointers.

Shared Reference Issue

Section Overview: In this section, the speaker talks about a shared reference issue.

Exclusive and Shared References

  • The existence of an exclusive reference implies that a shared reference shouldn’t exist.
  • Statics are never dropped, which means that we don’t actually need to deal with the global domain being dropped because it never gets dropped and that’s why there’s no unsafety there.
  • In that case, the drop here is kind of stupid because this can just never happen.

Skipping Global Domain

Section Overview: The speaker discusses the global domain and why it is never dropped.

Assertion Check for Global Domain

  • The speaker questions the need for a check on the global domain.
  • Asserting that the global domain can be dropped implies something false, so it’s not useful to think about it.
  • Static items do not call drop at the end of the program, so there is no need to check if they are active.

Debug Check for Hazard Pointers

  • The speaker looks at an implementation that walks through hazard pointers and asserts that they’re not active. This is a debug check and seems reasonable.

Type Annotation Needed

Section Overview: The speaker discusses type annotations needed in code.

Unreclaimed Type Annotation

  • The speaker adds an unreclaimed type annotation to indicate to the compiler that two types should be the same, but it’s still initialized to null.

Unused Variable Error

Section Overview: The speaker addresses an unused variable error in their code.

Pop Crate Not Needed

  • The speaker realizes that pop crate does not need to be used and fixes an unused variable error.

Debugging Segmentation Fault Error

Section Overview: The speaker attempts to debug a segmentation fault error in their code.

Running GDB Debugger

  • The speaker runs GDB debugger on their code.
  • They attempt to run with feels good option but encounter issues.
  • They explain that by adding an unreclaimed type annotation, they are indicating to the compiler that two types should be the same.

Troubleshooting Code

Section Overview: The speaker troubleshoots their code and attempts to get it to compile.

Compiling Issues

  • The speaker attempts to troubleshoot why their code is causing issues.
  • They attempt to run only feels good but encounter issues.
  • They search for a standard library path.
  • They realize they forgot what the issue was.

Restructuring Command

Section Overview: In this section, the speaker discusses restructuring a command and making changes to the codebase.

Relevant Commit

  • The speaker identifies a relevant commit that is needed for the restructuring.

Retired List Error

  • The speaker identifies an error in pushing to the retired list.
  • They explain that if sublist head is null, pushing an empty list is easy.

Charging Untagged List

Section Overview: In this section, the speaker discusses charging untagged lists and making changes to the codebase.

Num Shards Constant

  • The speaker explains that there’s a num shards of type probably you size which is eight and untagged is now actually multiple untagged.

Calc Shard Function

  • The calc shard function takes a tag as input and returns a u size. It uses the head pointer as the tag.
  • The speaker considers reordering functions and using default hasher instead of cryptographically secure hasher for performance reasons. [CUTOFF_LIMIT]

Generated by Video Highlight

https://videohighlight.com/video/summary/tGn0mQF0804