Abstract: The present disclosure generally relates to health-related user interfaces. In some embodiments, user interfaces for managing health-related data are described. In some embodiments, user interfaces for viewing health data are described. In some embodiments, user interfaces related to sharing health data are described.

Abstract: The present disclosure generally relates to health-related user interfaces. In some embodiments, user interfaces for managing health-related data are described. In some embodiments, user interfaces for viewing health data are described. In some embodiments, user interfaces related to sharing health data are described.

Abstract: The present disclosure generally relates to health-related user interfaces. In some embodiments, user interfaces for managing health-related data are described. In some embodiments, user interfaces for viewing health data are described. In some embodiments, user interfaces related to sharing health data are described.

Abstract: This application relates to a first computing device that stores a first set of data that is associated with an event can be configured to implement a method for resolving inconsistencies in synchronized data among multiple computing devices by carrying out the techniques described herein. In particular, the method can include the steps of (1) receiving, from a second computing device, a second set of data that is associated with the event, (2) in response to receiving a request to present data associated with the event: determining a presence of at least one inconsistency between respective corresponding data of the first and second sets of data, (3) applying rules to the at least one inconsistency to form resolved data, and (4) presenting the data associated with the event, where the data includes at least the resolved data.

Abstract: Observation and analysis based optimization of software code is disclosed. An expected value is chosen for a dynamic attribute that cannot be determined, prior to execution of the associated software code, to be guaranteed to have that expected value at runtime. An optimized version of the software code is generated, including one or more optimizations based on an assumption that the dynamic attribute will have the expected value. Non-exhaustive examples of a dynamic attribute include a variable type; a location in memory; a location in which a global object, property, or variable is stored; the contents of a global function or method; and a value of a global property or variable. A check is performed during execution of the optimized version of the software code, prior to executing the portion that has been optimized based on the assumption, to verify that the dynamic attribute has the expected value.

Abstract: Techniques for processing source code written in a traditionally interpreted language such as JavaScript, or another dynamic and/or interpreted language, are disclosed. In one example, compiled code associated with the source code is constructed and executed. An assumption on which a specific aspect of the compiled code is based (e.g., an optimization) is tested at a checkpoint of the compiled code. A roll over to fallback code is performed if the test indicates the assumption is not true.

Abstract: A device-independent intermediate representation of a source code is generated and stored, e.g., in a memory or other storage mechanism. The stored intermediate representation of the source code is used to generate a device-specific machine code corresponding to the source code. The stored intermediate representation may be updated, e.g., periodically, for example by obtaining an updated version of the source code and compiling the updated source code to generate an updated intermediate representation. The stored intermediate representation may be based on source code received from a device that is synchronized with which a compiling device that generates the device-specific machine code. In some cases, the stored intermediate representation may be used to generate for each of a plurality of devices a corresponding device-specific machine code.

Abstract: Techniques for processing computer code are disclosed. In one example, an indication that a computer code is to begin execution at a portion of code other than a starting portion of the code is received, and a runtime state associated with the portion of the code at which execution is to begin is constructed. In some examples, execution of the portion of code is initiated. In some examples, a program counter associated with the portion of the code is used to initiate execution of the code. In some examples, the computer code comprises a fallback code associated with a previously executing code.

Abstract: Techniques for processing computer code are disclosed. In one example, an indication that a computer code is to begin execution at a portion of code other than a starting portion of the code is received, and a runtime state associated with the portion of the code at which execution is to begin is constructed. In some examples, execution of the portion of code is initiated. In some examples, a program counter associated with the portion of the code is used to initiate execution of the code. In some examples, the computer code comprises a fallback code associated with a previously executing code.

Abstract: Techniques for processing source code written in a traditionally interpreted language such as JavaScript, or another dynamic and/or interpreted language, are disclosed. In one example, compiled code associated with the source code is constructed and executed. An assumption on which a specific aspect of the compiled code is based (e.g., an optimization) is tested at a checkpoint of the compiled code. A roll over to fallback code is performed if the test indicates the assumption is not true.

Abstract: Observation and analysis based optimization of software code is disclosed. An expected value is chosen for a dynamic attribute that cannot be determined, prior to execution of the associated software code, to be guaranteed to have that expected value at runtime. An optimized version of the software code is generated, including one or more optimizations based on an assumption that the dynamic attribute will have the expected value. Non-exhaustive examples of a dynamic attribute include a variable type; a location in memory; a location in which a global object, property, or variable is stored; the contents of a global function or method; and a value of a global property or variable. A check is performed during execution of the optimized version of the software code, prior to executing the portion that has been optimized based on the assumption, to verify that the dynamic attribute has the expected value.

Abstract: A device-independent intermediate representation of a source code is generated and stored, e.g., in a memory or other storage mechanism. The stored intermediate representation of the source code is used to generate a device-specific machine code corresponding to the source code. The stored intermediate representation may be updated, e.g., periodically, for example by obtaining an updated version of the source code and compiling the updated source code to generate an updated intermediate representation. The stored intermediate representation may be based on source code received from a device that is synchronized with which a compiling device that generates the device-specific machine code. In some cases, the stored intermediate representation may be used to generate for each of a plurality of devices a corresponding device-specific machine code.

Abstract: Variable type knowledge based call specialization is disclosed. An indication is received that a variable that is an argument of a function or operation the behavior of which depends at least in part on a data type of the argument is of a first data type. Machine code that implements a first behavior that corresponds to the first data type, but not a second behavior that corresponds to a second data type other than the first data type, is generated for the function or operation.

Abstract: The invention relates to optimizing software code execution during state transitions. The system handles changes in execution context using differential rule checking techniques. For instance, when a thread executing in a data processing system changes state, its new state may be subject to different rules than its previous state. To enforce these rules, the thread may be associated with software code that causes certain restrictions, such as memory restrictions, to be applied to the thread. In an interpretive environment, this can be implemented by detecting a state transition in an active thread, and responding to the state transition by associating the thread with a dispatch table that reflects its state change. The dispatch table may cause the thread to be associated with code that enforces those restrictions. In one example, different dispatch tables can be provided, each table reflecting a different state of a thread, and each causing a thread to be subject to different restrictions.

Abstract: A technique for implementing a data processor to determine if an exception has been thrown. Specifically, the technique may be used in an interpretive environment where a table known as a bytecode (upcode) dispatch table is used. The dispatch table contains addresses for code that implements each bytecode. When the interpreter executes normally, these addresses point to the basic target machine code for executing each bytecode. However, when an Asynchrounously Interrupted Exception (AIE) is thrown, then the dispatch table is repopulated so that all byte codes point to routines that can handle the exception. These may point to a routine, such as an athrow, that has been extended to handle the special case of the AIE. Alternatively, the rewritten table can point to a routine that is specifically written to handle the firing of an AIE. The table contents are restored to their prior state once the exception handling is complete.

Abstract: An invention is provided for managing memory that includes a heap memory and scoped memory. The scoped memory is managed separately from the heap memory, and includes defining a scope tree structure having a root node and a plurality of child nodes. The child nodes are capable of having respective child nodes, however each child node has only one parent node. Each child node corresponds to a scoped memory space that forms a logical memory pool corresponding to a particular scoped memory. During memory management, a thread is allowed to enter a particular child node only through the parent node of the particular child node. In this manner, a thread executing in a particular scooped memory space allocates memory from the scoped memory corresponding to the particular scoped memory space.