Structs in JS might change everything

Summiz Holo

JavaScript stru proposal advancing speed and concurrency through fixed layout mutable structs enhancing performance and memory efficiency

• The stru proposal in JavaScript has advanced to stage two, with the potential to significantly increase JavaScript's speed and concurrency capabilities.
• The example provided demonstrates how shared structs can allow for mutable values in shared state without the need for constant memory copying, enhancing performance.
• Current JavaScript concurrency relies heavily on post messages and shared array buffers, which are inefficient and slow due to serialization and the event loop.
• The proposal introduces four logical features for structs, which are fixed layout objects that behave like class instances with more restrictions, beneficial for optimization and analysis.
• Unlike traditional JavaScript objects, structs have a defined structure, preventing dynamic key additions, which enhances memory allocation efficiency and stability.

Shared memory multi-threading with shared structs, mutexes, unsafe blocks, and unshared structs for high-performance JavaScript applications

• Shared structs enable shared memory multi-threading, allowing multiple agents to access the same memory in parallel without message passing, unlocking significant power in concurrency.
• Mutex and conditions serve as higher-level abstractions for synchronizing access to shared memory, providing tools for managing concurrent access.
• The unsafe block acts as a syntactic guard rail for lexically scoping potentially racy access to shared structs.
• The proposal aims to enable high-performance applications in JavaScript by providing access to shared memory multi-threading and a structure that prioritizes performance over flexibility.
• The proposal introduces unshared structs as a refinement on JavaScript classes, with fixed layouts, sealed integrity, and specific initialization rules.
• Struct instances cannot be extended with new properties, ensuring a locked state once initialized, and all fields are initialized to undefined upon creation.
• Struct methods are non-generic and must have a this value that is an instance of the struct or its subclass, emphasizing strictness in their design.

Hierarchical struct definitions, distance calculations, shared struct restrictions, multi-threading memory sharing, and unsafe programming practices

• You can extend a struct from another struct, allowing for hierarchical struct definitions.
• The distance function calculates the distance between two points by subtracting their coordinates.
• Shared structs are designed for parallel access by multiple agents, with restrictions on their behavior and properties.
• Shared structs can only extend other shared structs and cannot contain instance methods or instance private names.
• Shared structs cannot point to unshared values and must reference either primitives or other shared structs.
• The introduction of shared structs enables proper memory sharing in multi-threading, improving performance and reducing memory overhead.
• The use of shared structs allows different threads to work on the same object without the need for copying values back and forth.
• The behavior of shared structs can lead to unsafe programming practices due to unpredictable execution order in multi-threaded environments.

Shared memory optimization, thread safety mechanisms, and unsafe code practices in concurrent programming

• An object tracking files for a compiler can utilize shared memory to distribute work across multiple workers without needing to reinstantiate in memory.
• Shared arrays are fixed-length arrays that can be optimized at an engine level and are a special case of shared structs.
• Memory model ensures that a given read can never tear from a shared struct, providing safety during concurrent operations.
• Writing thread-safe code requires additional components such as mutexes and conditions under atomics.
• The 'unsafe' keyword indicates a developer's intent to work with shared memory, signaling the need for special care during code reviews.
• The presence of an unsafe block aids in identifying data races and highlights potentially problematic areas in multi-threaded code.

Thread safety management, unsafe keyword implications, shared memory access complexities, and performance enhancement proposals

• Any thread safety concerns should be addressed by the developer as control flow exits the unsafe block.
• The unsafe keyword is a syntactic marker that applies to lexically scoped reads and writes of the fields of a shared struct instance within an unsafe block.
• You cannot read shared memory unless you are in an unsafe block, complicating the consumption of shared structs.
• The unsafe keyword indicates a transition boundary between thread-safe and unsafe code, similar to how async and await operate.
• The unsafe keyword does not entail any implicit synchronization or coordination, placing the onus on developers to manage thread safety.
• There are plans for async locking and waiting, as well as WebAssembly garbage collection interoperability.
• The proposal aims for faster performance, benefiting all developers, even if not everyone will directly write unsafe code.