Patent application number | Description | Published |
20090307431 | MEMORY MANAGEMENT FOR CLOSURES - Methods, software media, compilers and programming techniques are described for creating copyable stack-based closures, such as a block, for languages which allocate automatic or local variables on a stack memory structure. In one exemplary method, a data structure of the block is first written to the stack memory structure, and this may be the automatic default operation, at run-time, for the block; then, a block copy instruction, added explicitly (in one embodiment) by a programmer during creation of the block, is executed to copy the block to a heap memory structure. The block includes a function pointer that references a function which uses data in the block. | 12-10-2009 |
20100153912 | Variable type knowledge based call specialization - 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. | 06-17-2010 |
20100153929 | Converting javascript into a device-independent representation - 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. | 06-17-2010 |
20100153935 | Delayed insertion of safepoint-related code - Delayed insertion of safepoint related code is disclosed. Optimization processing is performed with respect to an intermediate representation of a source code. The optimized intermediate representation is analyzed programmatically to identify a safepoint and insert safepoint related code associated with the safepoint. In some embodiments, analyzing the optimized intermediate representation programmatically comprises determining where to place the safepoint within a program structure of the source code as reflected in the intermediate representation. | 06-17-2010 |
20100153936 | Deferred constant pool generation - Deferred constant pool generation is disclosed. Optimization processing is performed with respect to an intermediate representation of a source code. The optimized intermediate representation is used to generate a constant pool. In some embodiments, the source code comprises JavaScript, which is used to generate an LLVM or other intermediate representation (IR), which intermediate representation is optimized prior to a constant pool being generated. | 06-17-2010 |
20110167414 | SYSTEM AND METHOD FOR OBFUSCATION BY COMMON FUNCTION AND COMMON FUNCTION PROTOTYPE - Disclosed herein are systems, methods, and computer-readable storage media for obfuscating by a common function. A system configured to practice the method identifies a set of functions in source code, generates a transformed set of functions by transforming each function of the set of functions to accept a uniform set of arguments and return a uniform type, and merges the transformed set of functions into a single recursive function. The single recursive function can allocate memory in the heap. The stack can contain a pointer to the allocated memory in the heap. The single recursive function can include instructions for creating and explicitly managing a virtual stack in the heap. The virtual stack can emulate what would happen to the real stack if one of the set of functions was called. The system can further compile the source code including the single recursive function. | 07-07-2011 |
20120030653 | ASSUMPTION-BASED COMPILATION - 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. | 02-02-2012 |
20120030659 | CONSTRUCTING RUNTIME STATE FOR INLINED CODE - 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. | 02-02-2012 |
20120030661 | OBSERVATION AND ANALYSIS BASED CODE OPTIMIZATION - 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. In the event that it is determined at runtime that the dynamic attribute does not have the expected value, execution reverts to backup code that is not based on the assumption that dynamic attribute will have the expected value. | 02-02-2012 |
20130111446 | MEMORY MANAGEMENT FOR CLOSURES | 05-02-2013 |