Abstract: Methods, apparatuses and systems related to managing deck-specific read levels are described. The apparatus may include a memory array having the memory cells organized into two or more decks. The apparatus can determine a delay between programming the decks. The apparatus can derive and implement the deck-specific read levels by selectively adjusting a base read level with an offset level according to the delay and/or the targeted read location.

Abstract: An error associated with a read operation corresponding to a memory die of a memory sub-system is detected. In response to detecting the error, a first read throughput level of the memory sub-system is identified. A quantity of queues receiving operation requests is decreased, the decreased quantity of queues corresponding to a second read throughput level. A read retry operation associated with the memory die is initiated at the second read throughput level.

Abstract: A read operation is performed on a set of memory cells addressable by a first wordline (WL), wherein the set of memory cells is comprised by an open translation unit (TU_of memory cells of a memory device. Respective threshold voltage offset bins for each WL of a second plurality of WLs coupled to respective sets of memory cells comprised by the open TU are determined based on a threshold voltage offset bin associated with the first WL. Respective default threshold voltages for each WL of the first plurality of WLs are updated based on the respective threshold voltage offset bins for each WL of the second plurality of WLs.

Abstract: A programming operation is performed on a first set of memory cells addressable by a first wordline (WL), wherein the first set of memory cells are comprised by an open translation unit (TU) of memory cells. It is determined that a second set of memory cells comprised by the open TU are in a coarse programming state, wherein the second set of memory cells is addressable by a second WL. In response to determining that the second set of memory cells satisfies a threshold criterion, a programming state verify level associated with the second WL is reduced by a verify level offset. A programming state gate step size associated with each WL of the open TU is reduced by a predefined value. A programming operation is performed on the second set of memory cells using the reduced programming state verify level and the reduced programming state gate step size.

Abstract: A current cycle count associated with a memory sub-system is determined. The current cycle count is compared to a set of cycle count threshold levels to determine a current lifecycle stage of the memory sub-system. A temperature associated with the memory sub-system is measured. The temperature is compared to a set of temperature levels to determine a current temperature level of the memory sub-system. A write-to-read delay time corresponding to the current lifecycle stage and the current temperature level is determined.

Abstract: Returning a runtime type loaded from an archive in a module system is disclosed. Operations include (a) identifying, by a class loader implemented in a runtime environment, an archived runtime type loaded into an archive from a module source; (b) identifying a particular package associated with the archived runtime type; (c) determining that the particular package is defined to a runtime module that is defined to (i) the class loader or (ii) any class loader in the class loader hierarchy to which the class loader delegates; and (d) returning directly or indirectly, by the class loader, a runtime type loaded based on the archived runtime type from the archive.

Abstract: Returning a runtime type loaded from an archive in a module system is disclosed. Operations include (a) identifying, by a class loader implemented in a runtime environment, an archived runtime type loaded into an archive from a module source; (b) identifying a particular package associated with the archived runtime type; (c) determining that the particular package is defined to a runtime module that is defined to (i) the class loader or (ii) any class loader in the class loader hierarchy to which the class loader delegates; and (d) returning directly or indirectly, by the class loader, a runtime type loaded based on the archived runtime type from the archive.

Abstract: Returning a runtime type loaded from an archive in a module system is disclosed. Operations include (a) identifying, by a class loader implemented in a runtime environment, an archived runtime type loaded into an archive from a module source; (b) identifying a particular package associated with the archived runtime type; (c) determining that the particular package is defined to a runtime module that is defined to (i) the class loader or (ii) any class loader in the class loader hierarchy to which the class loader delegates; and (d) returning directly or indirectly, by the class loader, a runtime type loaded based on the archived runtime type from the archive.

Abstract: Returning a runtime type loaded from an archive in a module system is disclosed. Operations include (a) identifying, by a class loader implemented in a runtime environment, an archived runtime type loaded into an archive from a module source; (b) identifying a particular package associated with the archived runtime type; (c) determining that the particular package is defined to a runtime module that is defined to (i) the class loader or (ii) any class loader in the class loader hierarchy to which the class loader delegates; and (d) returning directly or indirectly, by the class loader, a runtime type loaded based on the archived runtime type from the archive.

Abstract: A class preloading mechanism that dynamically preloads classes at runtime in a virtual machine (VM) environment. Data structures representing preloaded classes may be stored in a persistent module corresponding to a classloader. A persistent module can be directly mapped or copied into a memory region at runtime so that the classes may not have to be loaded from the class file container. The preloaded classes are not fully linked and resolved. When a classloader receives a class request, the classloader looks up the preloaded class in the memory region and completes linking and resolution of the class. Persistent modules may be pre-generated and, for example, installed with an application. Alternatively, a persistent module for a class file container may be generated at runtime by preloading classes from the class file container into a memory region and storing data structures representing the classes as a persistent module.

Abstract: The present disclosure involves systems, methods, and/or computer-readable mediums for reducing load time of an application. The systems, methods, and/or computer-readable mediums store metadata in an archive prior to execution of an application. The metadata corresponds to a type of class loading operation used to load a class required by the application, where different types of class loading operations perform different security checks as a part of loading classes. During execution of the application, based on the metadata and based in part on a request for the class loading operation to load the class, it is determined whether the class is stored in the archive. When the class is stored in the archive, a particular type of class loading operation loads the class from the archive and the system checks that the particular type of the class loading operation matches the type of the class loading operation in the metadata.

Abstract: The present disclosure involves systems, methods, and/or computer-readable mediums for reducing load time of an application. The systems, methods, and/or computer-readable mediums store metadata in an archive prior to execution of an application. The metadata corresponds to a type of class loading operation used to load a class required by the application, where different types of class loading operations perform different security checks as a part of loading classes. During execution of the application, based on the metadata and based in part on a request for the class loading operation to load the class, it is determined whether the class is stored in the archive. When the class is stored in the archive, a particular type of class loading operation loads the class from the archive and the system checks that the particular type of the class loading operation matches the type of the class loading operation in the metadata.

Abstract: In general, the invention relates to a method. The method includes receiving notification, which includes context information, of a trap. The method further includes accessing, based at least partially upon the context information, a particular instruction that caused the trap, determining, based at least partially upon the context information, a particular address that is to be accessed by the particular instruction, updating a set of log information to indicate accessing of the particular address, causing subsequent accesses of the particular address to not give rise to a trap, after causing subsequent accesses of the particular address to not give rise to a trap, accessing the particular address, after accessing the particular address, causing subsequent accesses of the particular address to give rise to a trap, and causing the particular instruction to not be executed.

Abstract: A class preloading mechanism that dynamically preloads classes at runtime in a virtual machine (VM) environment. Data structures representing preloaded classes may be stored in a persistent module corresponding to a classloader. A persistent module can be directly mapped or copied into a memory region at runtime so that the classes may not have to be loaded from the class file container. The preloaded classes are not fully linked and resolved. When a classloader receives a class request, the classloader looks up the preloaded class in the memory region and completes linking and resolution of the class. Persistent modules may be pre-generated and, for example, installed with an application. Alternatively, a persistent module for a class file container may be generated at runtime by preloading classes from the class file container into a memory region and storing data structures representing the classes as a persistent module.

Abstract: A mechanism is disclosed for enabling multiple processes to share the same portion of physical memory. The first time an instance of a process is executed, a list of common components is compiled. The compiled code is then written into a newly created mappable data structure, which is stored into persistent storage. The next time an instance of that process is executed, the mappable data structure is mapped into a portion of the process instance's virtual memory space. This enables the process instance to invoke the compiled code for the common components. Multiple instances of the process may have their virtual memory spaces mapped to the same mappable data structure in this way. Thereafter, it is up to the operating system to load the contents of the mappable data structure into a portion of physical memory, and to ensure that all of the process instances share that physical memory portion.

Abstract: A mechanism is disclosed for implementing fast locking in a multi-threaded system. This mechanism enables fast locking to be performed even on an operating system platform that does not allow one thread to assign ownership of a lock on a mutex to another thread. In addition, the mechanism performs locking in a manner that ensures priority correctness and is low-memory safe. In one implementation, the priority correctness is achieved by using operating system mutexes to implement locking, and the low-memory safe aspect is achieved by pre-allocating a memory section to each thread. This pre-allocated memory section ensures that a thread will have sufficient memory to obtain a lock, even when a system is in a low-memory state. With this mechanism, it is possible to implement locking in a safe and efficient manner.

Abstract: A trap-based mechanism is provided for gaining greater visibility into the memory usage of a process. To detect and record the memory accesses of a process, a virtual address range (or a plurality of address ranges) of the process is set to a protected status. This address range represents the range of virtual addresses that are to be monitored for access. By setting the address range to a protected status, whenever a memory access (in one implementation, whenever a memory write) is made to a virtual address within that address range, a trap arises. When the trap arises, a trap handler is invoked. When invoked, the trap handler records the virtual address that was accessed. In this manner, the access of the virtual address is detected and recorded without having to add extensive instrumentation code to the process.

Abstract: In general, the invention relates to a method. The method includes receiving notification, which includes context information, of a trap. The method further includes accessing, based at least partially upon the context information, a particular instruction that caused the trap, determining, based at least partially upon the context information, a particular address that is to be accessed by the particular instruction, updating a set of log information to indicate accessing of the particular address, causing subsequent accesses of the particular address to not give rise to a trap, after causing subsequent accesses of the particular address to not give rise to a trap, accessing the particular address, after accessing the particular address, causing subsequent accesses of the particular address to give rise to a trap, and causing the particular instruction to not be executed.