EP3039536B1 - Accès simultanés à des données d'objets typés dynamiquement - Google Patents

Accès simultanés à des données d'objets typés dynamiquement Download PDF

Info

Publication number
EP3039536B1
EP3039536B1 EP14759421.2A EP14759421A EP3039536B1 EP 3039536 B1 EP3039536 B1 EP 3039536B1 EP 14759421 A EP14759421 A EP 14759421A EP 3039536 B1 EP3039536 B1 EP 3039536B1
Authority
EP
European Patent Office
Prior art keywords
property
code
instructions
access
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP14759421.2A
Other languages
German (de)
English (en)
Other versions
EP3039536A1 (fr
Inventor
Filip J. Pizlo
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc filed Critical Apple Inc
Publication of EP3039536A1 publication Critical patent/EP3039536A1/fr
Application granted granted Critical
Publication of EP3039536B1 publication Critical patent/EP3039536B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806—Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0815—Cache consistency protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45529—Embedded in an application, e.g. JavaScript in a Web browser
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/31—Programming languages or programming paradigms
    • G06F8/315—Object-oriented languages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/44—Encoding
    • G06F8/443—Optimisation
    • G06F8/4441—Reducing the execution time required by the program code
    • G06F8/4443—Inlining
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4488—Object-oriented
    • G06F9/449—Object-oriented method invocation or resolution
    • G06F9/4491—Optimising based on receiver type
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45508—Runtime interpretation or emulation, e g. emulator loops, bytecode interpretation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
    • G06F9/45516—Runtime code conversion or optimisation
    • G06F9/4552—Involving translation to a different instruction set architecture, e.g. just-in-time translation in a JVM
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62—Details of cache specific to multiprocessor cache arrangements
    • G06F2212/621—Coherency control relating to peripheral accessing, e.g. from DMA or I/O device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Definitions

  • the present invention relates generally to runtime accesses for dynamically typed data. More particularly, this invention relates to dynamically typed data sharing in concurrent executions of dynamic language based code.
  • Dynamic languages such as JavaScript, Ruby, Python, Perl, and PHP, etc. are increasingly being considered as a replacement for static languages, such as C and C++. Dynamic languages bring benefits such as programmer productivity and a relatively shallow learning curve.
  • static languages such as C and C++.
  • Dynamic languages bring benefits such as programmer productivity and a relatively shallow learning curve.
  • an obstacle to further adoption of dynamic languages - including JavaScript, Ruby, Python, and others - is the lack of a high-performance shared-memory concurrency mechanism, such as threads and locks, or libdispatch, which are trivially available in static languages. This problem is considered hard, and thus far unsolved, due to how objects work in dynamic languages.
  • inline cache is often used in high-performance implementations of JavaScript based code.
  • inline cache includes self-modifying code.
  • concurrent self modifying code that could execute on multiple processors may be both hard and slow.
  • adding concurrency to inline cache based implementation for JavaScript based code may be impractically expensive.
  • JavaScript as a language allows for elements to be added to objects after those objects have already been constructed. If a JavaScript based program is executed to add more properties to an object than can be contained in its inline property storage, then a separate out-of-line chunk of memory must be allocated to store its additional properties.
  • JavaScript Arrays are primarily used for indexed property storage. The presence of indexed properties on an object always requires allocation of an out-of-line index property storage object.
  • An event based transaction model speeds up parallelism. For instance a MapReduce framework allows concurrent event-based transactions, where data consistency issues are handles using eventual transactions. Eventual transactions do not require shared data to be consistent during the execution but only after commit has happened. E.g. the object property needs to be consistent only eventually i.e., after all parallel event callbacks have completed In particular, event based transactions are eventually committed using a lock/unlock mechanism.
  • Code generated from dynamic programming languages may include an enhanced object model to allow concurrent execution for data accesses during runtime.
  • An index structure may be introduced to an object model representing a dynamically typed object in addition to a type structure and a data payload storing property or field values of the object. Elements of the index structure may point at corresponding property values as an indirection for accessing the object.
  • dynamically typed program code (e.g. implementing a certain algorithm) may be allowed to concurrently perform each access operation to a single property value of the object via an additional indirection over the index structure of the object without creating race conditions.
  • Each access (e.g. load/store) operation for a single property value of the object may require multiple instructions and/or atomic operations. During the concurrent execution, these multiple instructions may be allowed to be interleaved in an unsynchronized manner.
  • inline cache initialization for accessing dynamically typed objects in a single thread may be off loaded to an interpreter without incurring unnecessary synchronization overhead.
  • a thread bias mechanism may be provided to detect whether a code block is executed in a single thread. Further, the number of inline cache initializations performed via a compiler, such as baseline JIT compiler, can be reduced to improve processing performance.
  • a code block may be a compilation unit, a section of source code, one or more source code files, or other applicable set of code statements (e.g. a consecutive portion of code specifications).
  • a compilation unit may refer to source code that is compiled and treated as one logical unit.
  • the compilation unit may include one or more entire source code files, but can also be a selected portion of a file or specific code sections. Declarations and definitions within a compilation unit can determine the scope of functions and data objects.
  • inline cache initializations in code blocks that are shared by multiple threads may be delayed and timed to reduce occurrences of required processor synchronizations (e.g. light points) to update executable code with the initializations.
  • each thread may store initialized code into a buffer during runtime.
  • a light point timer e.g. via a special thread
  • the number of invocations of expensive or slow synchronization operations required for inline cache initialization may be reduced.
  • whether an array object is of a flat array type may be dynamically tracked for a dynamic language based program.
  • Array elements of an array object of the flat array type may be stored in an optional inline storage within an object cell allocated to represent the array object.
  • the inline storage in the object cell may be limited by available memory space between adjacent object cells allocated in a memory.
  • the flat array type of the object may be based on whether the object represents an array and whether the inline storage of the object cell has sufficient memory space to store elements of the array.
  • An array object of the flat array type may allow array elements of the array object to be accessed within a object cell without additional memory loading via a pointer stored in the object cell.
  • a type system of a compiler which generates the executable code supporting a flat array type may allow the compiler to perform code optimizations based on the flat array type.
  • processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both.
  • processing logic comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both.
  • FIG. 1 is a network diagram illustrating an exemplary execution runtime for dynamic language based source codes retrieved from networked devices.
  • network system 100 may include one or more server applications, such as server application 101, hosted in one or more server devices to provide content available for client application 105 running in a client device.
  • server application 101 may be a web server and client application 105 may be a web browser.
  • Server 101 and client 105 may communicate with each other via network 103 based on, for example, internet protocols such as HTTP (Hypertext Transport Protocol) or other applicable protocols.
  • HTTP Hypertext Transport Protocol
  • content retrieved from server 101 may include web pages based on hypertext languages, such as HTML (Hypertext Markup Language), XML (Extensible Markup Language) or other markup language, embedded or linked (e.g. hyperlinked) with sources in a dynamic programming language, such as JavaScript, Ruby, Python or other dynamically typed languages.
  • Client 105 may dynamically download or fetch the linked sources for execution.
  • client 105 may dynamically compile the downloaded sources to optimize code execution for improving performance in a concurrent execution environment, including, for example, multiple threads of execution and/or multiple processors or processing units.
  • Figure 2 is a block diagram illustrating one embodiment of a system for concurrent and/or optimized execution for accessing dynamically typed objects.
  • system 200 may include operating environment 201, such as an operating system hosting client application 105 of Figure 1 , hosted by one or more processors.
  • Operating environment 201 may include compiler 205 to dynamically and/or continuously compile source code 203 into executable code 215 during runtime, e.g. based on Just-In-Time compilation.
  • Source code 203 may comprise programs in a dynamic programming language, such as JavaScript, Ruby, Python or other applicable dynamically typed language. Source code 203 may not specify or declare a type or shape of data or objects referenced in code statements. In one embodiment, source code 203 may be retrieved from a remote device, such as server 101 of Figure 1 , by a browser application or other applicable application running in operating environment 201. Compilation module 205 may be controlled by the browser application to perform browsing operations.
  • Compiler 205 may generate executable code 215 from source code 203.
  • compiler 205 may parse source code 203 statically or dynamically to emit intermediate code, bytecode or other applicable compiled code to performing data processing operations specified in source code 203.
  • Compiler 205 may provide object models representing dynamically typed objects to enable concurrent execution.
  • the object models may include indirect references to object values to allow sharing of common objects among multi threads or multi processes of executions in a multi processor environment.
  • optimized inline cache code generator module 207 may emit inline cache code for accessing (e.g. reading, writing, updating etc.) dynamically typed objects shared by multiple threads of execution.
  • the inline cache code emitted may support optimized runtime binding for concurrent execution without costly processor instruction synchronization.
  • the emitted code may include self modifying code capable of altering its own instructions while it is executing, for example, to initialize the inline cache code.
  • concurrent code execution module 217 may invoke interpreter 213 to perform operations based on code generated via compiler 205.
  • interpreter 213 can update bytecodes according to the self modifying instructions emitted via compiler 205 without activating instruction cache flush to synchronize instructions among different processors.
  • instruction cache flush module 219 may periodically invoke instruction cache flush via, for example, a dedicated thread.
  • compiler 215 may include optimized array object handler module 209 to provide executable code capable of identifying a special type (e.g. a flat array type) of dynamically typed data during runtime to optimize array data processing.
  • a special type e.g. a flat array type
  • compiler 215 may include optimized array object handler module 209 to provide executable code capable of identifying a special type (e.g. a flat array type) of dynamically typed data during runtime to optimize array data processing.
  • a special type e.g. a flat array type
  • concurrent code execution module 217 may achieve execution performance comparable to executing instructions for similar operations compiled with statically typed array data type (e.g. with a pre specified array type to optimize array data processing).
  • Concurrent code execution module 217 may invoke ACS (atomic compare and swap) handler module 221 based on executable code 215 to perform synchronized update operations without relying on costly software based lock/unlock mechanism.
  • ACS handler module 221 may be supported directly via processor hardware logic to ensure an atomic update operation is performed without interruption (e.g. within one processor instruction cycle).
  • types of runtime values for variables in a program or executable code may be identified and profiled (e.g. analyzed, summarized, etc.) during runtime while the program (e.g. executable code 217) is running. Based on the identified types through past execution history, future types of runtime values may be predicted to update or recompile the program to replace portions of the program or code taking advantage of the type predictions.
  • profiling data (e.g. indicating types of data or objects during runtime) may be collected in runtime data 211.
  • Compiler 205 may continuously optimize executable code 215 via recompilation based on the profiling data.
  • Profiling code may be embedded in executable code 215 to enable collection of the profiling data during runtime.
  • concurrent object models may be provided to allow concurrent executions of multiple machine instructions required to access (e.g. read, write, update, etc) a dynamically type object without corrupting memory heaps.
  • An object may include one or more fields or properties. The fields or properties of a dynamically typed object may come into existence during runtime when assigned via executable code for the first time.
  • a dynamic language based source program or code corresponding to the executable code may not include up front declarations of all fields of the object.
  • the object may be represented as a complex data structure (or shape). Each access to the object may include executing multiple machine instructions.
  • An example allocation of a cell representing a dynamically typed object based on a concurrent object model may include:
  • Cell.index may include an indirect reference to a payload or property values of the object.
  • Cell.index may provide one layer of indirection to allow the payload of the object to grow dynamically for concurrent access of the object data (e.g. property values) without causing racing conditions with inconsistent data access results.
  • the index itself may include an array indexed via field offsets and contains within it pointers to actual field values (or property values).
  • a typical object write program statement for accessing the object may be compiled differently depending on whether the object (e.g. o) already has a referenced field (e.g. f).
  • objects in dynamic languages such as JavaScript, do not have to have their fields pre declared up front, it may be common to perform an object write that creates a new field dynamically any time during the runtime.
  • AdditiveWrite() can guarantee that Cell.strucutre and Cell.index (e.g. representing structure and payload of the object) are changed at the same time in one atomic operation, such as CAS() operation.
  • a CAS (compare and switch) operation may be hardware or processor supported routine to ensure completion of both compare and switch operations atomically without interruption.
  • the CAS operation may be two words atomic to change both the structure (e.g. Cell.structure) and the index (e.g. Cell.index) of the object at the same time, provided that the two words are adjacently located in memory.
  • An index's Value ⁇ entries may be copied in AdditiveWrite() via 'reallocateIndex()' without copying any field values referenced by the entries.
  • Additional field value or Value box may be allocated via 'new Value()' in memory to hold one field or property value for the object. The value v can be stored into this newly allocated Value box.
  • an access to an object for deleting a field of the object based on the concurrent object model may guarantee that the index of the object (e.g. Cell.index) contains immutable pointers. Repeated deletions of fields may force an object to become a plain hashtable where optimizations for object accesses may be deactivated.
  • the concurrent object model may not reclaim a deleted field's memory if the deleted field of an object was added prior to the object becoming a plain hashtable.
  • Once an object becomes a hashtable e.g. in a hashtable mode), accesses to the object may use a per-object lock for synchronizing multiple accesses.
  • the garbage collection mechanism may compress or reclaim no longer used or inactive object indexes.
  • Figure 3 is a block diagram illustrating one exemplary runtime for multiple threads of executions sharing common dynamically typed objects.
  • Runtime 301 may be associated with system 200 of Figure 2 .
  • Runtime 301 may include portions of Runtime Data 211 of Figure 2 .
  • Shared Heap 303 may include runtime data or objects shared via multiple threads or processes, such as Thread1 315, Thread2 317, or other applicable threads or processes via one or more processors.
  • a dynamically typed Object O 319 shared between Thread1 315 and Thread2 317 may correspond to Object Cell 307.
  • Object O 319 may have dynamic properties represented via Structure 305 and one or more Property Value 311, 313, etc.
  • Structure 305 may specify a dynamic type of Object O 319.
  • Structure 305 may include property names of the dynamic properties and location information, such as memory offsets, to locate corresponding property values.
  • Object Cell 307 may reference its properties via direct or indirect pointers.
  • Object Cell 307 may include direct pointers pointing to Structure 305 and an indirect pointer for Property Values 311, 313 via Indices 309.
  • Indices 309 may store an array of pointers, each pointing to one property value (or property storage). Location information for each property value in Structure 305 may correspond to an index to the pointer array of Indices 309.
  • Operations for accessing Object 0 319 may be performed concurrently via Thread1 315 and Thread2 317.
  • Object access operations may include Read(), ExistingWrite(), AdditiveWrite() and/or Delete(), etc.
  • Each object access operation may require more than one atomic machine instruction.
  • the concurrent object model may allow adding additional properties to Object O 319 without copying existing Property Values 311, 313 to avoid race conditions between copying property values and updating property values.
  • Figure 4 illustrates exemplary allocations of a dynamically typed object shared via concurrent execution.
  • Example 400 may be based on some components of system 200 of Figure 2 .
  • object O 403 may be allocated in runtime data 211 of Figure 2 .
  • object O 403 may have property (E,F,G) indicated in structure 401 with corresponding property values 10, 12 and 8.
  • Object O 403 may reference indices 405 storing a pointer array with pointers pointing to the property values.
  • structure 401 may specify an offset for each property (e.g. E, F or G) to locate a pointer in indices 405 for the corresponding property value. For example, an offset of 2 may be identified for property F in Structure 401 to locate a pointer at offset 2 pointing to property storage 411 storing property value 12.
  • Object O 403 at time T1 423 may have a dynamic property corresponding to name-value pairs (or field values) as (E:10, F:12, G:8).
  • Threads T1 and T2 409 may simultaneously access Object O 403 without employing software synchronization mechanisms such as lock, critical section etc.
  • Object O 403 may be associated with a separate Structure 413 and a separate Indices 415 to dynamically grow its structure to accommodate newly added property (or attribute, field) H.
  • Structure 413 may include a copy of (previous) Structure 401 and attributes of the newly added property H.
  • Indices 415 may include a copy of (previous) Indices 415 and a pointer to a newly allocated property storage 421 storing property value 5.
  • the structure of Object O 403 may be reallocated from Structure 401 to Structure 413 and the indices of Object O 403 may be reallocated from Indices 405 to Indices 415.
  • Property storages for existing property values such as property storage 419 for property E, remain unchanged.
  • Property storage 411 is updated with property value 3 for property F. As existing property values remain stored in the same property storages, race conditions to update and relocate the property values can be avoided.
  • FIG. 5 is a flow diagram illustrating one embodiment of a process to generate concurrently executable instructions for accessing a dynamically typed object.
  • Exemplary process 500 may be performed by a processing logic, including, for example, some components of system 200 of Figure 2 .
  • the processing logic of process 500 may provide an object model in a memory during runtime to represent a dynamically typed object specified in a source code in a dynamic programming language such as JavaScript.
  • the source code may include statements specifying the object without declaring a type or structure for the object.
  • the object model can include a property structure, an index structure and/or value storages allocated for an object specified or referenced in the source code.
  • the property structure may be a structured data allocated in a memory (or address space of a memory) to store one or more existing properties of the object.
  • the existing properties may indicate a current dynamic type for the object during the runtime.
  • the value storages of the object may be allocated dynamically in the memory to store the existing property values of the object.
  • Each property value may separately correspond to one of the existing properties of the object.
  • the index structure of the object may be dynamically allocated to store references of the property values for the corresponding existing properties.
  • a reference may be a direct or indirect pointer (e.g. via executing a code or other applicable mechanisms) to a memory address to locate a value storage storing a property value.
  • the processing logic of process may generate first instructions for a first access to the object from the source code.
  • the source code may include program statements to update one of the existing properties with an updated property value for the first access.
  • the first access to the updated property value may indicate that the property has been deleted from for the object.
  • the first instructions may include operations such as ExistingWrite(), Delete() etc.
  • the first access to the object may be specified in the source to update an existing property of the object with the updated property value.
  • the first instructions may be compiled for the first access with an in-line cache code to include a reference to an expected property structure of the object.
  • the expected property structure may specify an offset location for locating a property storage for the existing property.
  • the offset location may be an index offset to an index structure for a pointer pointing to the property storage.
  • the first instructions may embed the expected property structure of the object and the offset location for the first access to the object.
  • the first instructions can embed an expected property structure of the object and an offset location for locating the property value of the existing property of the object.
  • the offset location may be specified in the expected property structure.
  • the offset location may include an index to a pointer array in the index structure.
  • the first instructions can include operations to determine whether the property structure of the object corresponds to the expected property structure of the object.
  • the first instructions may be executed to perform the first access to update the property storage with the updated property value via the offset location embedded in the first instructions without performing a table lookup operation if the property structure of the object corresponds to the expected property structure.
  • a compiler such as compiler 205 of Figure 2 , may generate the first instructions with the expected property structure for the object based on runtime data associated with a runtime execution.
  • the processing logic of process 500 may analyze a runtime profile, such as profile data collected in runtime data 211 of Figure 2 , to predict the expected profile structure for accessing the object.
  • the processing logic of process 500 may determine the expected property structure of the object based on heuristics or hints provided from an external input, such as user inputs or interfaces to other processing modules.
  • the processing logic of process 500 can generate second instructions for a second access to the object.
  • the second access may be specified by the source code to update an additional property with an additional property value for the object.
  • the existing properties of the object may not include the additional property when the second instructions are executed for the second access to the object.
  • the second instructions may be executed to allocate a separate property structure, a separate index structure and an additional value storage storing the additional property value for the object, the separate property structure storing the existing properties and the additional property, the separate index structure storing separate references to the value storages and an additional reference to the additional value storage corresponding to the additional property.
  • the processing logic of process 500 may execute the first instructions and the second instructions concurrently to perform the first access and the second access to the object, for example, via separate threads.
  • the first instructions may be executed to update one of the value storages corresponding to one of the existing properties (e.g. ExistingWrite()).
  • the second instructions may be executed to add an additional property to the existing properties of the object (e.g. AdditiveWrite()).
  • the object model (or concurrent object model) can include a property reference and an index reference.
  • the property reference pointing to the property structure may represent a dynamic type of the object.
  • the index reference pointing to the index structure may represent dynamic data values or property values of the object under the dynamic type.
  • the property structure may store offsets from the index reference of the index structure storing pointers or references to the property values. The offsets can allow indirect reference to the property values via the index structure.
  • the second instructions may include an atomic update operation on the object to simultaneously update both the property reference and the index reference.
  • the atomic update operation can be performed to compare the property reference with a reference to the property structure and set the property reference to refer to the updated property structure if the property reference corresponds to the reference to the property structure based on the comparison.
  • the compare and setting operations may be performed atomically via hardware support (e.g. built in logic in a processor).
  • the processing logic of process 500 can generate third instructions for a third access to the object from the source code.
  • the third access may be specified in the source code to retrieve or read a property value of the object.
  • the third instructions can include inline cache operations to determine whether the property reference of the object refers to the property structure.
  • the concurrent object model can allow the second and third instructions to be executed concurrently.
  • An inline cache code to access dynamically typed objects for optimized inline caching in a concurrent setting may be self modified during runtime.
  • the inline cache code may include a fast code path and a slow code path for accessing a dynamic object.
  • the inline cache code may determine whether to invoke the fast code path or the slow code path depending on a dynamic type or property of an object encountered.
  • a concurrent setting may include operating environments to allow concurrent execution via multi threads and/or multi processes hosted by one or more processors.
  • the modified inline cache code may be reset in the optimized inline caching for the processors to observe changes in instructions in the modified inline cache code.
  • the optimized inline caching may modify the inline cache code (e.g. in place editing) via init operations and chain operations.
  • the init operations may be performed to modify (or initialize) an unset (or uninitialized) inline cache code to specialize the inline cache code for a particular object property or structure.
  • the specialized inline cache code may include a fast code path which is invoked when an object with the particular object property is encountered.
  • the chain operations may be performed to modify the inline cache code (e.g. either initialized or uninitialized) to invoke the slow code path via a generated stub (e.g. a piece of code or a function pointer pointing to a generated function code).
  • Init operations may be performed without requiring processor instruction cache flushing to allow inline caches to get locked in (or initialized) in an efficient manner.
  • init operations may be performed by particular threads, e.g. thread biasing, to enable the initialization code to stabilize (e.g. initialize) most of its inline cache codes without a need for cross modifying code (e.g. between different threads).
  • Thread biasing may allow inline caches with code modification to run on one thread without a need for synchronization instructions among different threads.
  • modifications for code blocks shared by multiple threads in optimized inline caching may be buffered instead of making immediate code changes. These changes may be updated to the code blocks (e.g. via function pointers etc.) when reset operations are performed.
  • the expense of modifying an inline cache already running concurrently can be reduced.
  • Reset operations on the inline cache code may be initiated according to a specified time schedule and/or via an infrequently invoked system routine, such as garbage collection routines, to reduce impacts on overall system performance of the execution environments.
  • a watchpoint routine e.g. based on instruction cache flush module 219 of Figure 2 , may wake up according to the specified schedule (e.g. every 10ms or other applicable time interval) to perform the reset operations.
  • modifications for code blocks shared by multiple threads in optimized inline caching may be buffered instead of making immediate code changes. These changes may be updated to the code blocks (e.g. via function pointers etc.) when reset operations are performed.
  • the expense of modifying an inline cache already running concurrently can be reduced.
  • the initially generated code may have a dummy value for ExpectedStructure that may be guaranteed to give a false result for the comparison statement, i.e. o->structure not equal to ExpectedStructure.
  • ExpectedStructure and OffsetOfF may be modified. Since the values of ExpectedStructure and OffsetOfF are constants in the code, the modification can change the machine code sequence directly.
  • the optimized inline caching in a concurrent setting can provide guarantees of when other processors would observe these changes or editing of this machine code and in what order portions of the code are changed. For example, if OffsetOfF is edited prior to ExpectedStructure, another processor may be required to see the edits in the same order instead of an opposite order to remove the possibility for the fast path to be taken via that processor before observing changes of the value of OffsetOfF.
  • inline caching may speed up runtime method binding by remembering the results of a previous method lookup directly at a call site. Assuming that the objects that occur at a particular call site are often of the same type, performance can be increased by storing the result of a method lookup "inline", i.e. directly at the call site via inline caching.
  • call sites may be uninitialized, for example, when the values of ExpectedStructure and OffsetOfF are not known yet.
  • the language runtime Once the language runtime reaches a particular uninitialized call site, it may perform the dynamic lookup, store the result at the call site and initialize the call site. If the language runtime reaches the same call site again, it may retrieve the callee from it and invoke it directly without performing any more lookups.
  • optimized inline caching may allow concurrent self-modifying code modifying more than one word-sized code locations in the instructions without requiring that a processor observes the changed instructions immediately.
  • Processor cache flush mechanisms may be executed to synchronize the processor(s) with the changed instructions.
  • inline caching requires modifying more than one word-sized code locations, there may be no guarantee that a processor observes the changed instructions immediately due to processor instruction cache. Further, there may be no guarantee on the order and granularity of the memory loading a processor will perform when fetching instructions which have been modified. For example, two different instructions may be modified in a precise order for a code modification, such as a ⁇ first ⁇ write on one instruction followed by a ⁇ second ⁇ write on the other instruction. There may be no guarantee that the ⁇ second ⁇ write of the instructions is not decoded by some other processor before the ⁇ first ⁇ write of the instructions by that processor.
  • Cache flush mechanisms may include, for example, CPUID for Intel ® based processors or other similar flushing mechanisms on other hardware, like ARM ® .
  • cupid may be executed on a processor to enforce an order of instructions to be fetched by the processor.
  • a cpuid may be executed on multiple processors via a thread pinned to (e.g. limited to run on) each processor to wake up the processor, for example, to perform instruction cache flushing.
  • Cpuid may be executed as part of context switching, e.g. storing and restoring the state or context of a process so that execution can be resumed from the same point at a later time.
  • These points (or instructions) of execution e.g. light safe points or light points
  • inline cache initialization may be performed based on modifying assembly code, such as:
  • constants in the code such as a pointer-wide constant (e.g. 0 in “cmpq %0, (%rax)"), and/or a byte-wide or int-wide constant (e.g. 0 in "movq 0(%rax), %rax”) may be patched or modified with other values during the initialization.
  • the pointer-wide constant may represent a structure-to-check value and the byte-wide or int-wide constant may represent an offset-to-load-from value.
  • the constant value 0 in "compq $0" may ensure that a slow code path (e.g. "Lslow”) is invoked initially.
  • a processor of the assembly code may not observe a non-zero value for the constant for "cmpq” until the constant for "movq" has been patched (or initialized).
  • Optimized inline caching may allow inline cache codes to get locked in (or initialized) fairly quickly without requiring a light point (e.g. for flushing processor instruction cache) to initialize every inline cache code.
  • Initialized inline cache codes may be executed in optimizing inline caching without incurring additional overhead (e.g. to cause slower execution).
  • memory buffers may be employed to reduce potential high cost in modification of concurrently running inline cache codes may.
  • each code block may include a thread check guard for a bias-to thread at the top of the code block. During execution, this guard code can be skipped if the caller (to the code block) is already running on the biased-to thread. Inline cache code of code blocks that are biased (e.g. executed via the biased-to thread) may be allowed to be patched without concurrency consideration.
  • the code block may be marked (or modified) as requiring concurrent inline caches and the thread check guard may be patched away, such as replacing the thread check instruction with a nop (or no op code).
  • the presence of the thread check guard may force all other threads attempting to call into the code block to take a slow code path for the inline cache code in the code block.
  • the concurrent inline cache code may be invoked for inline caches that change state (e.g. initialized) after interpreter warm-up (e.g. initialization or pre-baking via an interpreter) and only in code blocks that are shared.
  • Operations which may be performed on an inline cache code may include, for example, init operations to take an unset inline cache and modify it so that it's specialized for some property/structure, chain operations to take an initialized or unset inline cache and modify it so that the slow path branch goes to a generated stub, watchpoint operations to reset an inline cache due to watchpoint execution (e.g. scheduled processor instruction cache flushing) and GC (garbage collection) operations to reset an inline cache during GC because objects were dead.
  • init operations to take an unset inline cache and modify it so that it's specialized for some property/structure chain operations to take an initialized or unset inline cache and modify it so that the slow path branch goes to a generated stub
  • watchpoint operations to reset an inline cache due to watchpoint execution (e.g. scheduled processor instruction cache flushing)
  • GC garbage collection operations to reset an inline cache during GC because objects were dead.
  • Init and chain operations may require two discrete operations.
  • the two operations may include: 1) patch the offset (e.g. offset-to-load-from value) into the load (e.g. load assembly code) and 2) patch the structure (e.g. structure-to-check value) into the compare (e.g. compare assembly code).
  • these two operations may include: 1) generate a stub (e.g. a piece of code representing a function) and 2) patch the slow path branch (e.g. a pointer in an assembly code) to the stub.
  • Optimized inline caching may prohibit a processor to observer (or see) operations (2) until the processor has already observed operations (1) without requiring performing a light point (e.g. instruction cache flushing) between operations (1) and (2) for each init and chain operations.
  • watchpoint routine When a watchpoint routine is fired or invoked (e.g. to stop the execution of an application whenever the value of a given expression changes, without specifying where it might occur), all threads may be required to observe the jump replacement (e.g. concurrent slow code path) or inline cache reset right away. For example, a thread requesting the watchpoint.fire() should not be allowed to proceed further until after all other threads observe the changes to their code. But watchpoints are less common.
  • Inline cached code block 713 may be generated for a function via concurrent inline code generator module 703 of Figure 7A .
  • Inline cached code block 713 may include slow concurrent code 715 for a concurrently slow code path and slow serial code 721 with a slow serial code path, each for object data access in the function.
  • Slow concurrent code 715 may be capable of self code modification when running concurrently by more than one thread.
  • slow concurrent code 715 may modify a code block for the function in code buffer 723 which is not yet invoked.
  • changes to code buffer 723 may be synchronized via a locking mechanism but without a need for processor instruction flushing.
  • the code block in code buffer 723 may become active when referenced (or pointed to) by code pointer 711.
  • Thread1 803 may wake up to call function foo of code block 809 after being notified of the completion of the compilation of function foo 807 via thread2 805.
  • thread1 803 is associated with a thread identifier different from thread2 805 (e.g. thread_2 of code block 809), execution of guard code S1 of code block 809 may cause thread1 803 to recompile function foo 807.
  • the source code block can include program statements specifying at least one access to an object.
  • the source code may not include any program statements declaring a type or structure for the object.
  • the object can be associated with a dynamic structure having one or more properties with corresponding property values.
  • a type of the object may correspond to the dynamic structure determined during runtime.
  • the initial inline code can have serial inline cache code to perform the access (e.g. read, write, update, delete or other applicable data loading/manipulation operations) to the object.
  • the serial inline cache code can include a serial slow code path and a fast code path.
  • a code path may be a sequence of assembly instructions to be executed by a processor.
  • the fast code path may be executed with a small number (e.g. less than 10) of assembly instructions with a performance overhead of about, for example, 5 nano seconds.
  • the serial slow code path may include a table lookup operation performed by the interpreter (e.g. with a performance overhead of about 100 nano seconds).
  • the serial inline cache code may include comparison operations to determine whether to perform the access to the object via the fast code path or the serial slow code path.
  • the concurrent inline code may be generated as a result of executing the guard code in the initial inline code.
  • the guard code may cause a recompilation operation to generate the concurrent inline code if the thread executing the guard code differs from a particular thread generating the initial inline code.
  • Both the initial inline code and the concurrent inline code may be compiled from a common source code block. Generating of the concurrent inline code may be based on modifications of the initial inline code. For example, the guard code of the initial inline code may be patched to be a no operation code to allow a thread to perform the concurrent inline cache code independent of an identity of the thread.
  • a copy of the concurrent inline code may be stored in a code buffer.
  • the copy of the concurrent inline code in the code buffer may be modified to update the constant parameters via, for example, self modifying code.
  • the modification of the copy of the concurrent inline may be performed asynchronously with the execution of the concurrent inline code among multiple threads.
  • the serial slow code path may be executed to perform the access of the object via table lookup or other applicable search operations which may be slow and require expensive processing resources.
  • the fast code path may be executed to perform the access of the object via direct memory loading operations (e.g. without a need to perform a lookup operation) via a memory address embedded inside the fast code path.
  • the concurrent inline cache code can have a concurrent slow code path for the access of the object via the table lookup operations.
  • the concurrent inline cache code may include instructions to determine whether to perform the access to the object via the concurrent slow code path or the fast code path.
  • the processing logic of process 1000 can execute the concurrent inline cache code via one or more threads to perform the function without invoking the interpreter.
  • the memory address in the fast code path may be reinitialized if the concurrent slow code path of the concurrent inline cache code is executed.
  • a flat array object or an inline stored array data object may be based on an object cell for a dynamically typed object specified in a dynamic programming language.
  • An object cell may be allocated with a fixed size identified at the time of allocation.
  • an object cell may include a type pointer (e.g. 8 byte), a data pointer (e.g. 8 byte) and an optional inline storage (e.g. a number of 64-bit or other fixed sized bit memory space) allocated, for example, adjacent or next to each other in sequence.
  • the inline storage (or inline property storage) may be an inline backing store in the object cell.
  • the type pointer may point to a type structure representing an object type.
  • the data pointer may point to a storage structure (e.g. a backing store) for storing property values for the object type.
  • Arrays in JavaScript may have a fixed size throughout their lifetime.
  • Array literals e.g. ['hello', 1, ⁇ ]
  • Arrays may be detected to grow within (or never grow beyond) a certain length based on profiling mechanisms (e.g. via profile data collected in Runtime Data 211 of Figure 2 ).
  • profiling mechanisms e.g. via profile data collected in Runtime Data 211 of Figure 2 .
  • the backing store to store indexed data of the array may be allocated along side the object cell of the array itself.
  • flat array objects representing indexed data may allow runtime optimization to compile (e.g. via JIT compiler) codes accessing or performing operations on the indexed data via the flat array objects.
  • the compiled codes may only operate on the flat array objects.
  • indexed data or array data may be stored in a butterfly storage structured to organize property values of an object (e.g. JavaScript object) in a bidirectional manner.
  • a storage structure to store property values of an object may be based on a butterfly storage.
  • the second 8 bytes of the 16-byte cell may be a pointer or data pointer to a secondary structure or a storage structure, such as a butterfly storage.
  • a storage structure such as a butterfly storage.
  • an optional number of 64-bit values used for inline non-indexed property storage may be allocated.
  • an object cell for a JavaScript (or other applicable dynamic language) based object may have a memory layout represented as (assuming a 64-bit word size): the structure pointer may be a type pointer addressed with offset 0 byte relative to the object cell; the butterfly pointer may be a data pointer addressed with offset 8 bytes; and the optional inline property storage may be addressed with offset 16 bytes.
  • Property values stored within the inline storage may be accessed without a need for an extra indirection via the butterfly pointer.
  • a compiler's type system may include a collection of rules that assign a type to various constructs-such as variables, expressions, functions or modules of a program. The compiler can also use this type information (e.g. whether an object is a flat array object or not) to generate code that takes advantage of inline stored array data to reduce number of runtime memory allocations, remove indirect memory loadings, etc.
  • the object model may include an object cell allocated in the memory.
  • the object cell can include a value pointer (or data pointer) and an inline storage.
  • the value pointer may include a reference to the property values stored in value storages allocated in the memory.
  • the properties of an object can have an array relationship to represent an array of data.
  • an object may be associated with an index type (or indexing type) identifiable via a compiler, such as compiler 205 of Figure 2 .
  • the index type may indicate which of a limited (e.g. predetermined) number of object types the object belongs to.
  • Each object type may be semantically associated with a compiler via, for example, a type system in the compiler for code optimization and/or generation.
  • the presence of an array relationship in an object may be identified based on program source and/or execution runtime analysis mechanisms. For example, a static analysis on the source code may indicate that a property name of an object corresponds to an integer value which may represent an array index.
  • the processing logic of process 1300 may determine if the inline storage is sized with sufficient space for the value storages to store the property value. For example, the amount of storage space for storing an array of data may depend on the length of the array (e.g. maximum number of indices) and the value type for each array element. The processing logic of process 1300 may dynamically detect the length of an array based on the number of property values added to an object representing an indexed array.
  • the index type of a flat array object may be updated to indicate the object is an array object but not a flat array object if the update property name corresponding to an out of bound index value for an array relationship is associated with the flat array object.
  • the out of bound index value may indicate, for example, that the inline storage of an object cell for the flat array object is sized with insufficient space to store an array of property values having an array length of the out of bound index value.
  • the guard code may be executed to dynamically determine whether to invoke a slow code path or a fast code path for accessing property values of an object.
  • the fast code path may be invoked if the property values have an array relationship and an inline storage of an object cell representing the object is sized with sufficient space as value storages to store the property values.
  • whether to invoke a fast code path may be based on an index type of an object.
  • the fast code path may be invoked via a guard code if the index type of the object indicates that the object is a flat array object.
  • Dynamically generated instructions for accessing property values of the object may include a memory loading operation to access the property values via a value pointer stored in an object cell representing the object. If the object is a flat array object, the instructions may be executed to locate the property values (e.g. stored in value storages) without performing the loading operation via the value pointer (e.g. directly from within an object cell).
  • a loop for accessing an object may be specified in a source code.
  • the loop may include multiple accesses to the property values of the object. If the index type of the object indicates that the object is a flat array object, the instructions generated for the multiple accesses to the object may be optimized to include one common guard code to determine whether to invoke a fast code path to for each of the multiple accesses to the object directly within the object cell instead of a separate guard code for each access to the object in the loop.
  • Figure 14 is a flow diagram illustrating one embodiment of a process to identify a flat array data type during runtime to generate instructions for iteratively accessing objects via flat arrays allocated inline.
  • Exemplary process 1400 may be performed by a processing logic including, for example, some components of system 200 of Figure 2 .
  • the object model representing, an object specified with one or more properties in the source code, each property having a property name associated with a property value
  • the object model including an object cell allocated in a memory, the object cell having a property pointer, a value pointer and an inline storage, the value pointer pointing to a value storage allocated for storing the property values, the property pointer pointing to a property storage allocated for storing the property names.
  • generating instructions for an iterative access of the object specified in the source code wherein the iterative access of the object corresponds to a plurality of accesses to separate property values of the object
  • the instructions include a guard code, a plurality of fast code paths and a slow code path, the slow code path to locate the value storages via the value pointer to locate the value storage outside of the cell object to perform the iterative access of the property value, the fast code path to perform the plurality of accesses to the separate property values within the object cell without checking the index type of the object, the guard code determining whether to invoke the slow code path or the fast code path for the iterative access to the object, wherein the fast code path is invoked if the flat array type of the object is identified.
  • the input/output devices 1515 are coupled to the system through input/output controllers 1517.
  • the volatile RAM (Random Access Memory) 1509 is typically implemented as dynamic RAM (DRAM) which requires power continually in order to refresh or maintain the data in the memory.
  • DRAM dynamic RAM
  • the mass storage 1511 is typically a magnetic hard drive or a magnetic optical drive or an optical drive or a DVD RAM or a flash memory or other types of memory systems which maintain data (e.g. large amounts of data) even after power is removed from the system. Typically, the mass storage 1511 will also be a random access memory although this is not required. While Figure 15 shows that the mass storage 1511 is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the present invention may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface or wireless networking interface.
  • the bus 1503 may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art.
  • An article of manufacture may be used to store program code.
  • An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions.
  • Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Devices For Executing Special Programs (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Human Computer Interaction (AREA)

Claims (15)

  1. Un procédé implémenté par machine de génération d'instructions exécutables simultanément pour l'accès à un objet à typage dynamique dans un langage à typage dynamique, le procédé comprenant :
    la génération (507), par un compilateur du langage à typage dynamique, d'un modèle d'objet dans une mémoire pendant un runtime, le modèle d'objet représentant l'objet à typage dynamique (403) spécifié dans un code source dans un langage de programmation dynamique, le code source comprenant des déclarations spécifiant l'objet à typage dynamique sans déclarer de type ou de structure pour l'objet, le modèle d'objet comprenant une cellule référençant une structure de propriétés (401) et une charge utile référençant une structure d'index (405) qui référencent indirectement des stockages de valeurs (411, 419) pour l'objet (403), la structure de propriétés (401) stockant une ou plusieurs propriétés existantes de l'objet (403), les stockages de valeur (411, 413) stockant une ou plusieurs valeurs de propriétés correspondant distinctement aux une ou plusieurs propriétés existantes, et la structure d'index (405) stockant des références aux valeurs de propriétés pour les propriétés existantes correspondantes ;
    la génération (503), à partir du code source, de premières instructions pour un premier accès à l'objet (403), le premier accès étant spécifié dans le code source pour mettre à jour l'une des propriétés existantes par une valeur de propriété mise à jour ;
    la génération (505), à partir du code source, de secondes instructions pour un second accès à l'objet (403), le second accès étant spécifié dans le code source pour mettre à jour une propriété additionnelle par une valeur de propriété additionnelle à l'objet et pour allouer une structure de propriétés distincte (413), une structure d'index distincte (415) et un stockage de valeurs additionnelles (421), la structure de propriétés distincte (413) servant à stocker les propriétés existantes et la propriété additionnelle ne faisant pas partie des propriétés existantes, la structure d'index distincte (415) servant à des références distinctes aux stockages de valeurs et une référence additionnelle au stockage de valeurs additionnelles (421) correspondant à la propriété additionnelle, et pour mettre à jour la propriété additionnelle par stockage d'une valeur de propriété additionnelle pour l'objet (403) dans le stockage de valeurs additionnelles (421) ; et
    l'exécution (507) des premières instructions et des secondes instructions simultanément pour effectuer le premier accès et le second accès à l'objet (403) via des threads distincts.
  2. Le procédé de la revendication 1, dans lequel les premières instructions et les secondes instructions sont exécutées simultanément via des threads distincts sans synchronisation des instructions.
  3. Le procédé de la revendication 1, dans lequel le code source spécifie l'objet sans spécifier un type de l'objet.
  4. Le procédé de la revendication 1, dans lequel les premières instructions sont exécutées pour mettre à jour l'un des stockages de valeurs correspondant à ladite une des propriétés existantes par la valeur de propriété mise à jour.
  5. Le procédé de la revendication 1, dans lequel le code source spécifie ladite une des propriétés existantes pour le premier accès à l'objet, dans lequel une structure de propriétés attendue de l'objet spécifie un emplacement décalé pour la localisation d'un stockage de propriété pour ladite une propriété existante, dans lequel la première instruction incorpore la structure de propriétés attendue de l'objet et l'emplacement décalé pour le premier accès à l'objet et dans lequel les premières instructions comprennent des opérations pour déterminer si la structure de propriétés correspond ou non à la structure de propriétés attendue de l'objet.
  6. Le procédé de la revendication 5, dans lequel les premières instructions effectuent le premier accès pour mettre à jour le stockage de propriété par la valeur de propriété mise à jour via l'emplacement décalé incorporé, sans effectuer d'opération de correspondance en table si la structure de propriétés de l'objet correspond à la structure de propriétés attendue.
  7. Le procédé de la revendication 6, dans lequel la structure de propriétés attendue de la première instruction est basée sur des données de runtime associées à l'exécution des instructions pour l'accès de l'objet.
  8. Le procédé de la revendication 6, dans lequel la structure de propriétés attendue de la première instruction est basée sur une heuristique de runtime appliquée via des entrées utilisateur.
  9. Le procédé de la revendication 1, dans lequel le code source spécifie un second identifiant de propriété pour le second accès à l'objet, dans lequel la génération des secondes instructions comprend :
    la détermination que le second identifiant de propriété n'identifie aucune des propriétés existantes stockées dans la structure de propriétés.
  10. Le procédé de la revendication 1, dans lequel le modèle d'objet inclut une référence de propriétés et une référence d'index, la référence de propriétés représentant un type dynamique de l'objet et la référence d'index représentant des valeurs de données dynamiques de l'objet avec le type dynamique, et dans lequel la référence de propriétés renvoie à la structure de propriétés distincte suite à l'exécution simultanée de la première et de la seconde instruction.
  11. Le procédé de la revendication 10, dans lequel les secondes instructions comprennent une opération de mise à jour atomique sur l'objet, l'opération de mise à jour atomique comprenant :
    la comparaison de la référence de propriétés avec une référence à la structure de propriétés ; et
    le paramétrage de la référence de propriétés pour renvoyer à la structure de propriétés mise à jour si la référence de propriétés correspond à la référence à la structure de propriétés sur la base de la comparaison, la comparaison et le paramétrage étant effectués de façon atomique.
  12. Le procédé de la revendication 10, comprenant en outre :
    la génération de troisièmes instructions pour un troisième accès à l'objet à partir du code source, le troisième accès étant spécifié dans le code source pour récupérer une valeur de propriété correspondant à l'une distincte des propriétés existantes de l'objet, les troisièmes instructions comprenant des opérations pour déterminer si la référence de propriétés de l'objet renvoie ou non à la structure de propriétés, et la seconde et la troisième instruction étant exécutées simultanément.
  13. Le procédé de la revendication 10, dans lequel la structure de propriétés stocke des décalages par rapport à la référence d'index pour les références stockées dans la structure d'index, les décalages servant à référencer de façon indirecte les valeurs de propriété via les références dans la structure d'index.
  14. Un support de stockage non transitoire lisible par machine avec des instructions dedans qui, lorsqu'elles sont exécutées par une machine, font en sorte que la machine mette en œuvre un procédé selon l'une des revendications 1 à 13.
  15. Un système informatique comprenant :
    une mémoire stockant des instructions pour la génération d'instructions exécutables de façon simultanée pour l'accès à un objet à typage dynamique dans un langage à typage dynamique et pour stockage, et un code source pour effectuer une tâche de traitement de données, le code source spécifiant au moins un objet, un premier accès à l'objet et un second accès à l'objet, le premier et le second accès à l'objet s'exécutant dans des threads distincts ;
    un processeur couplé à la mémoire pour exécuter les instructions provenant de la mémoire, le processeur étant configuré pour :
    générer (507) un modèle d'objet dans une mémoire pendant un runtime, le modèle d'objet représentant l'objet à typage dynamique (403) spécifié dans un code source dans un langage de programmation dynamique, le code source comprenant des déclarations spécifiant l'objet à typage dynamique sans déclarer de type ou de structure pour l'objet, le modèle d'objet comprenant une cellule référençant une structure de propriétés (401) et une charge utile référençant une structure d'index (405) qui référencent indirectement des stockages de valeurs (411) pour l'objet, la structure de propriétés (401) stockant une ou plusieurs propriétés existantes de l'objet (403), les stockages de valeur (411) stockant une ou plusieurs valeurs de propriétés correspondant distinctement aux une ou plusieurs propriétés existantes, et la structure d'index (405) stockant des références aux valeurs de propriétés pour les propriétés existantes correspondantes ;
    générer (503), à partir du code source, des premières instructions pour un premier accès à l'objet (403), le premier accès étant spécifié dans le code source pour mettre à jour l'une des propriétés existantes par une valeur de propriété mise à jour ;
    générer (505), à partir du code source, des secondes instructions pour le second accès à l'objet (403), le second accès étant spécifié dans le code source pour mettre à jour une propriété additionnelle par une valeur de propriété additionnelle à l'objet et pour allouer une structure de propriétés distincte (413), une structure d'index distincte (415) et un stockage de valeurs additionnelles (421), la structure de propriétés distincte (413) servant à stocker les propriétés existantes et la propriété additionnelle ne faisant pas partie des propriétés existantes, la structure d'index distincte (415) servant à des références distinctes aux stockages de valeurs et une référence additionnelle au stockage de valeurs additionnelles (421) correspondant à la propriété additionnelle, et pour mettre à jour la propriété additionnelle par stockage d'une valeur de propriété additionnelle pour l'objet (403) dans le stockage de valeurs additionnelles (421) ; et
    exécuter les premières instructions et les secondes instructions simultanément pour effectuer le premier accès et le second accès à l'objet (403) via des threads distincts, indépendamment de l'ordre d'exécution de la première et de la seconde instruction, l'objet possédant des valeurs de propriétés incluant la valeur de propriété mise à jour et la valeur de propriété additionnelle consécutive à l'exécution.
EP14759421.2A 2013-08-30 2014-08-22 Accès simultanés à des données d'objets typés dynamiquement Active EP3039536B1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361872386P 2013-08-30 2013-08-30
US14/231,464 US9501409B2 (en) 2013-08-30 2014-03-31 Concurrent accesses of dynamically typed object data
PCT/US2014/052289 WO2015031193A1 (fr) 2013-08-30 2014-08-22 Accès simultanés à des données d'objets typés dynamiquement

Publications (2)

Publication Number Publication Date
EP3039536A1 EP3039536A1 (fr) 2016-07-06
EP3039536B1 true EP3039536B1 (fr) 2022-04-20

Family

ID=52584914

Family Applications (3)

Application Number Title Priority Date Filing Date
EP14759421.2A Active EP3039536B1 (fr) 2013-08-30 2014-08-22 Accès simultanés à des données d'objets typés dynamiquement
EP14759420.4A Active EP3039535B1 (fr) 2013-08-30 2014-08-22 Optimisation de cache en ligne concurrente en accès à des objets dynamiquement typés
EP14762164.3A Active EP3039537B1 (fr) 2013-08-30 2014-08-25 Type dépendant de la taille dans l'accès à des objets de matrice dynamiquement typés

Family Applications After (2)

Application Number Title Priority Date Filing Date
EP14759420.4A Active EP3039535B1 (fr) 2013-08-30 2014-08-22 Optimisation de cache en ligne concurrente en accès à des objets dynamiquement typés
EP14762164.3A Active EP3039537B1 (fr) 2013-08-30 2014-08-25 Type dépendant de la taille dans l'accès à des objets de matrice dynamiquement typés

Country Status (5)

Country Link
US (3) US9251071B2 (fr)
EP (3) EP3039536B1 (fr)
KR (3) KR101769260B1 (fr)
CN (3) CN105493041B (fr)
WO (3) WO2015031193A1 (fr)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10482194B1 (en) * 2013-12-17 2019-11-19 EMC IP Holding Company LLC Simulation mode modification management of embedded objects
US9207914B2 (en) 2013-12-20 2015-12-08 Microsoft Technology Licensing, Llc Execution guards in dynamic programming
US9104434B2 (en) * 2013-12-20 2015-08-11 Microsoft Technology Licensing, Llc Property accesses in dynamically typed programming languages
US9740504B2 (en) * 2014-01-23 2017-08-22 Qualcomm Incorporated Hardware acceleration for inline caches in dynamic languages
US9710388B2 (en) 2014-01-23 2017-07-18 Qualcomm Incorporated Hardware acceleration for inline caches in dynamic languages
US10776378B2 (en) * 2014-07-09 2020-09-15 Oracle Interntional Corporation System and method for use of immutable accessors with dynamic byte arrays
EP3086233B1 (fr) * 2015-04-23 2020-05-06 CODESYS Holding GmbH Procédé et système permettant de mesurer le temps d'exécution au moyen de points de surveillance
US10614126B2 (en) 2015-05-21 2020-04-07 Oracle International Corporation Textual query editor for graph databases that performs semantic analysis using extracted information
JP6603495B2 (ja) * 2015-07-01 2019-11-06 株式会社Ｌｉｘｉｌ 抗菌・抗ウィルス性コーティング剤
US10127025B2 (en) * 2015-07-22 2018-11-13 Oracle International Corporation Optimization techniques for high-level graph language compilers
US10025582B2 (en) 2015-12-10 2018-07-17 International Business Machines Corporation Applying program patch sets
US9971570B2 (en) 2015-12-15 2018-05-15 Oracle International Corporation Automated generation of memory consumption aware code
CN106897051B (zh) * 2015-12-24 2022-01-25 北京奇虎科技有限公司 一种进程清理的方法及装置
US11263110B1 (en) * 2015-12-31 2022-03-01 EMC IP Holding Company LLC Inter-object validation system and method for the objects of a test system
CN105912398A (zh) * 2016-04-06 2016-08-31 北京小米移动软件有限公司 内存检测方法及装置
US9952982B2 (en) * 2016-06-06 2018-04-24 International Business Machines Corporation Invoking demote threads on processors to demote tracks indicated in demote ready lists from a cache when a number of free cache segments in the cache is below a free cache segment threshold
US9852202B1 (en) 2016-09-23 2017-12-26 International Business Machines Corporation Bandwidth-reduced coherency communication
CN108920149B (zh) * 2017-03-29 2020-12-08 华为技术有限公司 编译方法和编译装置
CN108694185B (zh) * 2017-04-07 2021-06-04 成都阜特科技股份有限公司 一种数据存储与提取的方法
US10691609B2 (en) 2017-07-24 2020-06-23 International Business Machines Corporation Concurrent data erasure and replacement of processors
US10585945B2 (en) 2017-08-01 2020-03-10 Oracle International Corporation Methods of graph-type specialization and optimization in graph algorithm DSL compilation
US10877757B2 (en) * 2017-11-14 2020-12-29 Nvidia Corporation Binding constants at runtime for improved resource utilization
CN108154463B (zh) * 2017-12-06 2021-12-24 中国航空工业集团公司西安航空计算技术研究所 一种模型化gpu显存系统管理方法
CN108647241A (zh) * 2018-04-09 2018-10-12 宁波诺信睿聚投资有限责任公司 数据存储方法、装置、计算机设备及计算机可读存储介质
US10552185B2 (en) * 2018-05-24 2020-02-04 International Business Machines Corporation Lightweight and precise value profiling
CN110825531B (zh) * 2018-08-14 2023-05-30 斑马智行网络(香港)有限公司 针对动态类型语言的优化方法、装置、设备以及存储介质
CN110908850A (zh) * 2018-09-14 2020-03-24 阿里巴巴集团控股有限公司 数据获取方法及装置
CN109725955A (zh) * 2018-12-30 2019-05-07 北京城市网邻信息技术有限公司 一种访问对象属性方法、装置、设备及存储介质
WO2021068102A1 (fr) * 2019-10-08 2021-04-15 Intel Corporation Réduction des coûts de contrôle de type compilateur par spéculation de fil et mémoire transactionnelle matérielle
CN110753056B (zh) * 2019-10-25 2022-05-13 高秀芬 一种非交互式加密访问控制方法
CN110825369A (zh) * 2019-11-07 2020-02-21 四川长虹电器股份有限公司 一种基于java语言的代码自动生成的方法
US11188316B2 (en) 2020-03-09 2021-11-30 International Business Machines Corporation Performance optimization of class instance comparisons
US11275671B2 (en) * 2020-07-27 2022-03-15 Huawei Technologies Co., Ltd. Systems, methods and media for dynamically shaped tensors using liquid types
US11487565B2 (en) * 2020-10-29 2022-11-01 Hewlett Packard Enterprise Development Lp Instances of just-in-time (JIT) compilation of code using different compilation settings
US11307834B1 (en) * 2020-11-11 2022-04-19 Fileonq, Inc. Platform for rapid application development
CN112957068B (zh) * 2021-01-29 2023-07-11 青岛海信医疗设备股份有限公司 超声信号处理方法及终端设备
US11940994B2 (en) * 2021-10-29 2024-03-26 Salesforce, Inc. Mechanisms for maintaining chains without locks
US20230229525A1 (en) * 2022-01-20 2023-07-20 Dell Products L.P. High-performance remote atomic synchronization
CN115373645B (zh) * 2022-10-24 2023-02-03 济南新语软件科技有限公司 一种基于可动态定义的复杂数据包操作方法及系统

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815719A (en) * 1996-05-07 1998-09-29 Sun Microsystems, Inc. Method and apparatus for easy insertion of assembler code for optimization
US5915114A (en) * 1997-02-14 1999-06-22 Hewlett-Packard Company Dynamic trace driven object code optimizer
GB2377283B (en) * 2001-04-10 2004-12-01 Discreet Logic Inc Initialising modules
US7062761B2 (en) 2001-07-10 2006-06-13 Micron Technology, Inc. Dynamic arrays and overlays with bounds policies
US7010783B2 (en) * 2002-03-18 2006-03-07 Sun Microsystems, Inc. Method and apparatus for deployment of high integrity software using reduced dynamic memory allocation
US7805710B2 (en) 2003-07-15 2010-09-28 International Business Machines Corporation Shared code caching for program code conversion
US7610473B2 (en) 2003-08-28 2009-10-27 Mips Technologies, Inc. Apparatus, method, and instruction for initiation of concurrent instruction streams in a multithreading microprocessor
US7519639B2 (en) 2004-01-05 2009-04-14 International Business Machines Corporation Method and apparatus for dynamic incremental defragmentation of memory
US7526760B1 (en) 2004-03-17 2009-04-28 Sun Microsystems, Inc. Methods for implementing virtual method invocation with shared code
JP2005346407A (ja) 2004-06-03 2005-12-15 Hitachi Ltd 動的コンパイルにおけるインライン展開実施方法
US20060242635A1 (en) * 2005-04-21 2006-10-26 Scott Broussard Method and system for optimizing array sizes in a JAVA virtual machine
US20080005728A1 (en) * 2006-06-30 2008-01-03 Robert Paul Morris Methods, systems, and computer program products for enabling cross language access to an addressable entity in an execution environment
US8146054B2 (en) 2006-12-12 2012-03-27 International Business Machines Corporation Hybrid data object model
US7761676B2 (en) 2006-12-12 2010-07-20 Intel Corporation Protecting memory by containing pointer accesses
US7975001B1 (en) 2007-02-14 2011-07-05 The Mathworks, Inc. Bi-directional communication in a parallel processing environment
CN101271398B (zh) * 2007-03-23 2010-06-09 北京大学 多路分支结构的识别方法
US8001070B2 (en) 2007-12-17 2011-08-16 Honeywell International Inc. Object oriented rule-based system and method
US8392881B1 (en) 2008-05-13 2013-03-05 Google Inc. Supporting efficient access to object properties in a dynamic object-oriented programming language
US8108649B2 (en) 2008-06-13 2012-01-31 International Business Machines Corporation Method of memory management for server-side scripting language runtime system
WO2010033997A2 (fr) 2008-09-22 2010-03-25 Fiji Systems, Llc Récupération de place en temps réel par fragmentation hybride
US8370822B2 (en) 2008-11-20 2013-02-05 Apple Inc. Compiling techniques for providing limited accuracy and enhanced performance granularity
US20110138373A1 (en) 2009-12-08 2011-06-09 American National Laboratories, Inc. Method and apparatus for globally optimizing instruction code
US9195486B2 (en) 2010-07-30 2015-11-24 Apple Inc. Observation and analysis based code optimization
JP5466601B2 (ja) 2010-08-31 2014-04-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コード生成方法、システム及びプログラム
US9009726B2 (en) 2010-12-10 2015-04-14 Microsoft Technology Licensing, Llc Deterministic sharing of data among concurrent tasks using pre-defined deterministic conflict resolution policies
US8819649B2 (en) 2011-09-09 2014-08-26 Microsoft Corporation Profile guided just-in-time (JIT) compiler and byte code generation
US8972952B2 (en) 2012-02-03 2015-03-03 Apple Inc. Tracer based runtime optimization for dynamic programming languages

Also Published As

Publication number Publication date
CN105493042A (zh) 2016-04-13
KR20160040257A (ko) 2016-04-12
CN105493042B (zh) 2019-09-10
EP3039535A1 (fr) 2016-07-06
CN105493040A (zh) 2016-04-13
KR20160040254A (ko) 2016-04-12
US9501409B2 (en) 2016-11-22
CN105493040B (zh) 2019-09-20
KR20160038044A (ko) 2016-04-06
KR101769260B1 (ko) 2017-08-17
CN105493041A (zh) 2016-04-13
CN105493041B (zh) 2019-04-09
WO2015031286A1 (fr) 2015-03-05
US20150067658A1 (en) 2015-03-05
US9251071B2 (en) 2016-02-02
EP3039535B1 (fr) 2022-05-04
US20150067267A1 (en) 2015-03-05
KR101778479B1 (ko) 2017-09-26
WO2015031193A1 (fr) 2015-03-05
WO2015031192A1 (fr) 2015-03-05
KR101872625B1 (ko) 2018-08-02
US20150067639A1 (en) 2015-03-05
US9672152B2 (en) 2017-06-06
EP3039536A1 (fr) 2016-07-06
EP3039537A1 (fr) 2016-07-06
EP3039537B1 (fr) 2022-04-20

Similar Documents

Publication Publication Date Title
EP3039536B1 (fr) Accès simultanés à des données d'objets typés dynamiquement
US6721944B2 (en) Marking memory elements based upon usage of accessed information during speculative execution
US8402224B2 (en) Thread-shared software code caches
El Hajj et al. SAVI objects: sharing and virtuality incorporated
Von Praun et al. Conditional memory ordering
Wu et al. Compiler and runtime techniques for software transactional memory optimization
Liu et al. Safe-by-default concurrency for modern programming languages
Fulton et al. Compilation techniques for real-time Java programs
Gregersen et al. Towards a Dynamic-update-enabled JVM
Mohamedin et al. ByteSTM: Virtual machine-level Java software transactional memory
CN101630268A (zh) 同步优化的方法及设备
Guan et al. Multithreaded optimizing technique for dynamic binary translator CrossBit
You et al. A static region‐based compiler for the Dalvik virtual machine
Choi HW-SW co-design techniques for modern programming languages
Veldema Compiler and Runtime Optimizations for Fine-Grained Distributed Shared Memory Systems
박혁우 A Study on Optimization of Compilation Process for JavaScript Engine
Jeon et al. Reuse of JIT compiled code based on binary code patching in JavaScript engine
Krintz et al. Understanding the potential of interpreter-based optimizations for Python
Deacon A Generic Approach to Object Migration using Specialised Methods
Estébanez López et al. New data structures to handle speculative parallelization at runtime
Gunnerson Deeper into C#
Liao et al. DJ: A Transparent Java-Integrated Data Access System
WO2000070452A1 (fr) Gestion dynamique de versions d'objets destinee a prendre en charge l'execution d'un programme a dimension spatio-temporelle

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160205

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: APPLE INC.

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180823

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Ref document number: 602014083329

Country of ref document: DE

Free format text: PREVIOUS MAIN CLASS: G06F0009450000

Ipc: G06F0008410000

RIC1 Information provided on ipc code assigned before grant

Ipc: G06F 9/455 20180101ALI20211027BHEP

Ipc: G06F 9/448 20180101ALI20211027BHEP

Ipc: G06F 8/41 20180101AFI20211027BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20211207

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602014083329

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1485711

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220515

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20220420

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1485711

Country of ref document: AT

Kind code of ref document: T

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220822

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220721

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220720

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220820

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602014083329

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20230123

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20220822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220822

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

REG Reference to a national code

Ref country code: BE

Ref legal event code: MM

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220822

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220831

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20220822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT; INVALID AB INITIO

Effective date: 20140822

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20220420

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20240625

Year of fee payment: 11