Systems and methods for continuous in-memory versioning

1. A memory subsystem comprising:

a memory device configured to store a first data unit, a second data unit, and a third data unit, wherein the first, second, and third data units have a set of physical memory locations on the memory device, and wherein the first, second, and third data units store respective versions of data, the respective versions including a clean version of the data indicating that the data is uncorrupted and checkpointed, a dirty version of the data indicating that the data has been updated from the clean version, and a speculative version of the data indicating that the data has been updated and is in process of being checkpointed, and wherein the first, second, and third data units store metadata including state information and a dirty commit timestamp of the data; and

a processing device, operatively coupled to the memory device, the processing device configured to:

receive, from a host system, a first memory command associated with a logical memory address, the logical memory address mapped to each of the set of physical memory locations of the memory device;

in response to receiving the first memory command, determine which of the set of physical memory locations to access based on the state information and the dirty commit timestamp; and

perform a data operation on the first, second, or third data unit based on the determination,

wherein the first memory command comprises a rollback operation due to a failure event having a failure timestamp, and wherein to perform the data operation, the processing device is configured to:

determine from the state information whether the first data unit is in a clean state, a dirty state, or a speculative state; and

modify the state information of the first data unit to one of: the clean state, the dirty state, or the speculative state.

2. The memory subsystem of claim 1 , wherein the first data unit is stored on a first bank of the memory device, and the second data unit is stored on a second bank of the memory device.

3. The memory subsystem of claim 1 , wherein the state information is a 4-bit encoding representing one of nine states.

4. The memory subsystem of claim 3 , wherein the nine states include a clean first data unit, a dirty first data unit, a speculative first data unit, a clean second data unit, a dirty second data unit, a speculative second data unit, a clean third data unit, a dirty third data unit, and a speculative third data unit, corresponding to a data state of the first, second, or third data unit.

5. The memory subsystem of claim 1 , wherein the first memory command comprises a write memory command to store a data value, and wherein to perform the data operation, the processing device is configured to:

determine from the state information whether the first data unit is in a clean state, dirty state, or speculative state; and

conditionally store the data value to the first data unit or second data unit depending on the state information.

6. The memory subsystem of claim 5 , wherein the processing device is configured to modify the state information in response to writing the data value to the first data unit to indicate that the second data unit is in a dirty state.

7. The memory subsystem of claim 1 , wherein the first memory command comprises a global commit operation, and wherein to perform the data operation, the processing device is configured to:

determine from the state information whether the first data unit is in a clean state, dirty state, or speculative state;

conditionally modify the state information based on whether the first data unit is in the clean state, dirty state, or speculative state; and

update the dirty commit timestamp with a current time.

8. The memory subsystem of claim 7 , wherein the processing device is configured to:

receive, from the host system, a write memory command to store a data value; and

in response to receiving the second memory command, store the data value in the first, second, or third data unit based on the state information and the time the write memory command was issued.

9. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a clean state and the write memory command was issued before the global commit operation was issued, the data value is stored in the second data unit, and the state information is updated to indicate that the second data unit is in the dirty state.

10. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a clean state and the write memory command was issued after the global commit operation was issued, the data value is stored in the second data unit and, the state information is updated to indicate that the third data unit is in the speculative state.

11. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a dirty state and the write memory command was issued before the global commit operation was issued, the data value is stored in the first data unit, and the state information is updated to indicate that the first data unit is in the dirty state.

12. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a dirty state and the write memory command was issued after the global commit operation was issued, the data value is stored in the second data unit, and the state information is updated to indicate that the second data unit is in the speculative state.

13. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a speculative state and the write memory command was issued before the global commit operation was issued, the data value is stored in the first data unit, and the state information is updated to indicate that the first data unit is in the speculative state.

14. The memory subsystem of claim 8 , wherein when the state information indicates that the first data unit is in a speculative state and the write memory command was issued after the global commit operation was issued, the data value is stored in the second data unit, and the state information is updated to indicate that the first data unit is in the speculative state.

15. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a clean state and the failure timestamp is after the dirty commit timestamp, the state information is saved to indicate that the first data unit is in the clean state.

16. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a clean state and the failure timestamp is before the dirty commit timestamp, the state information is saved to indicate that the third data unit is in the clean state.

17. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a dirty state and the failure timestamp is after the dirty commit timestamp, the state information is saved to indicate that the third data unit is in the clean state.

18. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a dirty state and the failure timestamp is before the dirty commit timestamp, the state information is saved to indicate that the second data unit is in the clean state.

19. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a speculative state and the failure timestamp is after the dirty commit timestamp, the state information is saved to indicate that the third data unit is in the clean state.

20. The memory subsystem of claim 1 , wherein when the state information indicates that the first data unit is in a speculative state and the failure timestamp is before the dirty commit timestamp, the state information is saved to indicate that the second data unit is in the clean state.

21. A method comprising:

receiving, at a memory device from a host system, a first memory command associated with a logical memory address, the logical memory address mapped to each of a set of physical memory locations of the memory device, the set of physical locations being of a first data unit, a second data unit, and a third data unit on the memory device, wherein the first, second, and third data units store respective versions of data, the respective versions including a clean version of the data indicating that the data is uncorrupted and checkpointed, a dirty version of the data indicating that the data has been updated from the clean version, and a speculative version of the data indicating that the data has been updated and is in process of being checkpointed;

using the set of physical locations to load the first, second, and third data unit into a row buffer;

loading metadata associated with the first, second, and third data units, the metadata including state information and a dirty commit timestamp of the data;

determining which of the first, second, or third data units to access based on the state information and the dirty commit timestamp; and

performing a data operation on the first, second, or third data unit based on the determination,

wherein the first memory command comprises a rollback operation due to a failure event having a failure timestamp, and wherein performing the data operation comprises:

determining from the state information whether the first data unit is in a clean state, a dirty state, or a speculative state; and

modify the state information of the first data unit to one of: the clean state, the dirty state, or the speculative state.

22. The method of claim 21 , wherein the first data unit is stored on a first bank of the memory device, and the second data unit is stored on a second bank of the memory device.

23. The method of claim 21 , wherein the state information is a 4-bit encoding representing one of nine states.