Classifications

• • 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
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/36—Preventing errors by testing or debugging software
  • G06F11/3604—Software analysis for verifying properties of programs
  • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis

Definitions

• Metadata is often consumed by development tools in order to provide a richer tooling experience.
• metadata may indicate that a function or method may not be made inline.
• a compiler may use this metadata at compile time to create a binary executable where the function or method indicated by the metadata is not inline. After use, the metadata is discarded and cannot be retrieved on inspecting the compiled binary.
• the metadata described above can only include what is known or can be calculated at compile time.
• metadata of a managed runtime environment may be set by imperative statements included in code of a program executing in the managed runtime environment.
• the metadata may be associated with lookup data that identifies the metadata.
• the lookup data may be formed from an identifier supplied by an imperative statement and an identifier of a logical element which may be explicitly or implicitly supplied.
• the metadata may be computed at parse time, run time, or another time and may be computed based on state available to a managed runtime environment at the time the metadata is computed.
• FIG. 1 is an exemplary environment that includes a software development system in accordance with aspects of the subject matter described herein;
• FIG. 2 is a block diagram that illustrates an exemplary metadata subsystem in accordance with aspects of the subject matter described herein;
• FIG. 3 is a block diagram that illustrates exemplary components that may interact with each other in accordance with aspects of the subject matter described herein;
• FIG. 4 is a flow diagram that generally represents exemplary actions that may occur in obtaining and storing metadata in accordance with aspects of the subject matter described herein;
• FIG. 5 is a flow diagram that generally represents exemplary actions that may occur from a metadata manager's perspective in accordance with aspects of the subject matter described herein.
• the term “includes” and its variants are to be read as open-ended terms that mean “includes, but is not limited to.”
• the term “or” is to be read as “and/or” unless the context clearly dictates otherwise.
• the term “based on” is to be read as “based at least in part on.”
• the terms “one embodiment” and “an embodiment” are to be read as “at least one embodiment.”
• the term “another embodiment” is to be read as “at least one other embodiment.”
• references to an item generally means at least one such item is present and a reference to an action means at least one instance of the action is performed.
• first the terms “first”, “second”, “third” and so forth may be used. Without additional context, the use of these terms in the claims is not intended to imply an ordering but is rather used for identification purposes.
• first version and “second version” do not necessarily mean that the first version is the very first version or was created before the second version or even that the first version is requested or operated on before the second version. Rather, these phrases are used to identify different versions.
• a programming interface may be viewed as any mechanism, process, protocol for enabling one or more segment(s) of code to
• a programming interface may be viewed as one or more
• segment of code in the preceding sentence is intended to include one or more instructions or lines of code, and includes, e.g., code modules, objects, subroutines, functions, and so on, regardless of the terminology applied or whether the code segments are separately compiled, or whether the code segments are provided as source, intermediate, or object code, whether the code segments are utilized in a runtime system or process, or whether they are located on the same or different machines or distributed across multiple machines, or whether the functionality represented by the segments of code are implemented wholly in software, wholly in hardware, or a combination of hardware and software.
• Headings are for convenience only; information on a given topic may be found outside the section whose heading indicates that topic.
• FIGS. 1-3 are block diagram that represent an exemplary environment in which aspects of the subject matter described herein may operate.
• the components illustrated in FIGS. 1-3 are exemplary and are not meant to be all-inclusive of components that may be needed or included.
• the components and/or functions described in conjunction with FIGS. 1-3 may be included in other components (shown or not shown) or placed in subcomponents without departing from the spirit or scope of aspects of the subject matter described herein.
• the components and/or functions described in conjunction with FIGS. 1-3 may be distributed across multiple devices.
• Computing devices may include one or more personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, cell phones, personal digital assistants (PDAs), gaming devices, printers, appliances including set-top, media center, or other appliances, automobile-embedded or attached computing devices, other mobile devices, hardware capable of executing instructions, distributed computing environments that include any of the above systems or devices, and the like.
• PDAs personal digital assistants
• a virtual environment is an environment that is simulated or emulated by a computer.
• the virtual environment may simulate or emulate a physical machine, operating system, set of one or more interfaces, portions of the above, combinations of the above, or the like.
• the machine is sometimes called a virtual machine.
• a virtual machine is a machine that, to software executing on the virtual machine, appears to be a physical machine.
• the software may save files in a virtual storage device such as virtual hard drive, virtual floppy disk, and the like, may read files from a virtual CD, may communicate via a virtual network adapter, and so forth.
• More than one virtual environment may be hosted on a single computer. That is, two or more virtual environments may execute on a single physical computer. To software executing in each virtual environment, the virtual environment appears to have its own resources (e.g., hardware) even though the virtual environments hosted on a single computer may physically share one or more physical devices with each other and with the hosting operating system.
• resources e.g., hardware
• FIG. 1 is an exemplary environment that includes a software development system in accordance with aspects of the subject matter described herein.
• the system 105 may include software development components 1 10, a store 150, and may include other components (not shown).
• the software development components may include a source code editor 115, a runtime manager 120, a debugger 125, a profiler 130, other development tool(s) 135, a metadata subsystem 140, and other components (not shown).
• the term component is to be read to include all or a portion of one or more devices, a collection of one or more software modules or portions thereof, some combination of one or more software modules or portions thereof and one or more devices or portions thereof, and the like.
• the store 150 may include any storage media capable of storing data involved with software development.
• data is to be read broadly to include anything that may be represented by one or more computer storage elements.
• Logically, data may be represented as a series of 1 's and O's in volatile or non-volatile memory.
• data may be represented according to the capabilities of the storage medium.
• Data may be organized into different types of data structures including simple data types such as numbers, letters, and the like, hierarchical, linked, or other related data types, data structures that include multiple other data structures or simple data types, and the like.
• Some examples of data include information, program code, program state, program data, other data, and the like.
• the store 150 may be implemented as a file system, database, volatile memory such as RAM, other storage, some combination of the above, and the like and may be distributed across multiple devices.
• the store 150 may be external, internal, or include components that are both internal and external to the devices that host components of the software development system 105.
• the software development components 110 may be operable to work with a dynamic programming language.
• techniques that are described herein may also be applied to non-dynamic programming language environments.
• a dynamic programming language environment may perform some actions a non-dynamic programming language environment performs at or before compile time, if at all. For example, during program execution, a dynamic programming language environment may add new code, extend objects and definitions, modify a type system, and the like.
• Some exemplary dynamic programming languages include ActionScript, BASIC, BeanShell, Clojure, ColdFusion, Lisp, Groovy, JavaScript, VBScript, Perl, PHP,
• the source code editor 115 may allow a software developer to enter, delete, and modify source code of a program.
• the source code editor 115 may display source code of a program on a display and receive input via the user interface.
• the runtime manager 120 may launch a runtime environment to execute source code.
• a runtime environment may include a Web browser.
• a runtime environment may include one or more components that allow code to be executed outside of a Web browser.
• the debugger 125 may interact with a runtime environment to test and debug a program.
• the debugger 125 may allow a software developer to execute a program step- by-step, pause the program at certain points within the program, track values of variables and memory locations, modify program state, and the like.
• the debugger 125 may allow a software developer to indicate the conditions under which the debugger 125 is notified of exceptions. For example, a software developer may want to be notified of exceptions that are raised in user code but not to be notified of exceptions that are raised in library code.
• the profiler 130 may be used to collect statistics regarding execution of a program. For example, the profiler 130 may measure usage of memory, usage of particular instructions, frequency and duration of functions calls, other statistics, and the like. To collect the statistics, the profiler 130 may interact with the runtime environment, may be a part of the runtime environment, may reside in a lower layer that allows the profiler 130 to see what code is executed, or may operate in other ways known to those skilled in the art.
• the other development tool(s) 135 represent any other development tools that may be included in the software development system 105.
• the metadata subsystem 140 may include one or more components that allow metadata to be associated with logical elements of a program.
• Metadata may include static data (e.g., the value "5") or dynamic data that is available or computed at parse time, compilation time, run time, or some other time. Metadata may be specified by providing static data, code that when executed produces data, a reference to code that when executed produces data, or the like.
• Metadata does not influence the logical flow of the program but may influence the behavior of the environment in which the program executes. For example, metadata may be used by a runtime to determine whether an exception is to be raised to a debugger, but the metadata does not affect results calculated by the program.
• Metadata may be associated with logical elements of a program.
• Some exemplary logical elements include functions, files, code containers, lexical scopes, current stack frames, stack of calling scope, properties, classes, prototypes, worker threads, specific call instances, specific object instances, delegates, global scope, other logical elements, and the like.
• a logical element may or may not inherit metadata from its parent (e.g., containing or calling logical element) based on a configuration or a parameter passed to an API, for example.
• This association of metadata with a logical element may allow a runtime to obtain the metadata based on a logical element and state that is available via the runtime. This association may also allow the calculation of all or a portion of the metadata based on state of the program.
• the specific logical element to which to associate metadata may be explicitly indicated or inferred.
• Metadata may be set via an application programming interface (API).
• API application programming interface
• the metadata may indicate data that is immediately available or that may be calculated at runtime. For example, the metadata may be calculated based on inspecting a relevant scope/stack chain.
• the API may include required and optional parameters.
• Zero or more of the parameters may include static data (e.g., data that may be calculated or determined by data included in the parameter) while zero or more of the parameters may be calculated based on runtime state.
• static data e.g., data that may be calculated or determined by data included in the parameter
• zero or more of the parameters may be calculated based on runtime state.
• metadata may be set for one or multiple metadata identifiers. There is no intention, however, that the types described below are all-inclusive or exhaustive of the types that may be used in accordance with the teachings herein. Indeed, based on the teachings herein, those skilled in the art may recognize other types of parameters that may be used without departing from the spirit or scope of aspects of the subject matter described herein.
• Some exemplary types of parameters include:
• An identifier to associate with the metadata may include a parameter that allows a caller of the API to indicate an identifier that is to be associated with the metadata. Subsequently, this identifier may be used to obtain the metadata from the metadata subsystem 140.
• Specific call instance it may be desirable to have metadata associated with a specific invocation of a function. For example, instead of having the metadata associated with every call to the function, it may be desirable to have the metadata associated with a certain call to the function or a set of calls to the function. This may be accomplished through the use of a specific call instance.
• a specific call instance may be identified via a function name and a number or a set of numbers.
• the number(s) may indicate specific
• a statement setting metadata may include an identifier of the function and a number corresponding to the specific call.
• metadata associated with a metadata identifier may be collected into a set. Each time a statement is executed to set metadata for the identifier, data may be added to the set that indicates the context (e.g., the scope or other data that identifies the statement that was executed) as well as the payload provided via the statement. This data may later be used to identify metadata for the identifier for a specific call or set of calls.
• the API may include a parameter that indicates the type of logical element with which the metadata is to be associated. This is sometimes referred to herein as the scope to which the metadata may be applied. This parameter together with the scope from which the API is called may be used to determine a logical element with which to associate the metadata. For example, if the API is called from the scope of a block within a function and the parameter indicates the logical element of the metadata is a function, the metadata may be associated with the function (not the block).
• the call may be ignored, an error may be generated, or the metadata may be stored with information that indicates that the API was called from a global scope.
• An "applies-to" parameter may also be used by the runtime to tune the runtime's behavior. For example, an applies-to parameter that indicates that the metadata is global may be used by the runtime to create a global variable that is modified each time the metadata is changed. As another example, an applies-to parameter that indicates that the metadata is for a function may be used by the runtime to remove the executable code (e.g., from compiled code created at runtime) that calls the API after the API has been called once from the function.
• An applies-to parameter may be inferred by the logical element from which the API is called. For example, if the API is called from a global scope, the metadata may be associated with a global scope. If the API is called from a function, the metadata may be associated with the function scope. If the API is called from within a lexical scope, the metadata may be associated with the lexical scope.
• the API may include a parameter that indicates a specific logical element with which to associate the metadata.
• the API may allow a caller to indicate a function other than the function from which the API is called.
• the logical element may be inferred.
• a logical element may be inferred to be a scope (e.g., function, block, file, or the like) that includes the call to the API.
• the API may include a parameter that indicates how many times a statement may be used to call the API. For example, in some cases it may be desirable to have a statement to set metadata only call the API once. For example, it may be useful to know whether a function has ever been called during the execution of a program. In another embodiment, it may be useful to know whether a loop has been executed once.
• a runtime may remove the executable code (e.g., from compiled code created at runtime or at compile time) that calls the API after the API has been called the specified number of times from the desired scope.
• Other techniques may be used to remove or otherwise disable an instruction that sets the metadata.
• Some examples of such techniques include providing a callback with the metadata where the callback indicates whether the instruction is to be removed or otherwise disabled, setting a property, and the like.
• Another example includes calling an API, providing a metadata identifier, and indicating that the instruction is to be removed or otherwise disabled, or the like.
• the above examples are not intended to be all-inclusive or exhaustive. Indeed, based on the teachings herein, those skilled in the art may recognize other techniques that may be used to remove or otherwise disable an instruction that sets metadata without departing from the spirit or scope of aspects of the subject matter described herein.
• a recursion parameter may include a parameter that how the metadata is to be applied when recursion occurs. This parameter may indicate that the metadata may be associated with a specific level of the recursion so that a metadata consumer may obtain the least recent, most recent, or some other time at which the metadata was set during the recursion.
• a relationships parameter The API may allow a parameter that indicates a relationship of the call to other current stack frames in order to identify a logical element.
• Some examples of relationships parameters include first setter wins, last setter wins, set metadata and ignore all subsequent setters in nested frames, set metadata for the current frame only, and the like. In first setter wins, the metadata set by the first stack frame to set the metadata is retained while other metadata that is attempted to be set by later stack frames is discarded or ignored. In last setter wins, the metadata set by the last stack frame to set the metadata is retained while other metadata that is attempted to be set by later stack frames is discarded or ignored.
• a callback parameter In one embodiment, one or more callback functions may be provided as parameters to the API. For example, a statement such as:
• the callback function GenValue may be called by the runtime to provide metadata.
• the callback function may use runtime state to compute the metadata.
• calculation of the metadata may be deferred to a time after the statement is encountered in the code.
• the runtime may lazily wait to call the GenValue function until the runtime needs the metadata.
• the API may include a parameter that indicates when the metadata setting statement is to be evaluated.
• the parameter may indicate that the metadata setting statement is to be evaluated during first parse, second parse, or Nth parse, during execution, during first compilation or re-compilation, or during some other phase.
• the API may include a parameter that indicates the metadata.
• the payload parameter may include metadata or may include or reference instructions (e.g., programming statements) for creating the metadata using program state that is available during execution of the program.
• a payload may include the actual metadata, code that when executed generates the metadata, or a callback (e.g., a reference to code) that when called generates the metadata.
• Some exemplary examples of types of calls to the API include:
• the API may combine data that could be specified by separate parameters by allowing information about the metadata to be specified in an object with properties.
• an object e.g., objfoo
• code snippet One example of this is illustrated by the following code snippet:
• an object includes two properties.
• the name property specifies an identifier of the metadata while the applies-to property indicates the logical elements the metadata may be applied to.
• one or more of the properties may be computed based on state that exists during execution.
• a reference to a function is passed as a parameter to the API.
• This function may include statements that return or calculate data used by the API.
• the function may be called when the metadata is requested by a metadata consumer.
• the function may be called immediately and the return data stored in a metadata store.
• the function may be called at one or more other times.
• a reference to a location accessible via a network is passed as a parameter to the API.
• the location may be a place to store the metadata.
• the location may indicate a service that may be called to store the metadata.
• the metadata subsystem 140 may maintain information about the scope from which the API is called.
• the API may be called from various nested scopes
• a function Bar may have nested logical elements such as:
• the API may store the identifier (i.e., foo) and each payload together with sufficient information to identify the scope of the metadata.
• the first SetMetadata call may have a scope of the function Bar(), while the second SetMetadata call may have the scope of the unnamed block (e.g., the code after the first SetMetadata statement), and the third SetMetadata call may have the scope of the function Bar2().
• the metadata returned by the API may depend on the metadata identifier and the logical element. For example, to precisely specify a specific payload, both the metadata identifier (e.g., "foo"), and the scope (e.g., Bar, unnamed block, or Bar2) may be specified.
• Metadata may be disabled for a program as a whole or for individual metadata calls.
• the following exemplary implementations are contemplated:
• the runtime may find a set metadata call, calculates the metadata based on static information included in the metadata call, and associates the metadata with logical element. Thereafter, the metadata call is stripped out, disabled, or ignored.
• an API may allow a metadata call to pass a parameter that indicates that after the current metadata call succeeds (and generates metadata) that thereafter, the metadata call is stripped out, disabled, or ignored.
• a runtime may include logic to expand a phrase found in a function into one or more metadata calls to set metadata for a logical element.
• a phrase such as SetAllMetadata() in a function may be expanded by the runtime into one or more metadata calls within the function.
• the phrase SetAllMetadata() may be defined elsewhere and may be in-lined by the runtime or another component replacing it with its defined statements prior to execution. This may be helpful, for example, where the same metadata needs to be set for multiple functions and may also help to eliminate code clutter.
• helper code may be referred to in a function.
• a function may include the following code: Function Fl() ⁇
• the statement SetAllMetadata() may refer to helper code that is defined elsewhere. In executing the helper code, the runtime may walk up the stack one frame to set metadata as if set in Fl without in- lining the helper code. This technique may also be used in other functions in which the statement SetAllMetadata() is found.
• the SetMetadata call may be encoded as a comment or other code that is generally not executed. Parsers or compilers that understand the syntax of the SetMetadata comment may set attributes based on the comment while other parsers may ignore the comment. In one implementation this may be used to mark methods that are to be exposed.
• a function may include a statement as follows:
• FIG. 2 is a block diagram that illustrates an exemplary metadata subsystem in accordance with aspects of the subject matter described herein.
• the metadata subsystem may include a metadata injector 205, an interface 210, a metadata manager 215, stores 220-221, and other components (not shown).
• the metadata subsystem may associate logical elements 225 with metadata and may store identifiers together with the metadata in the store 221.
• the logical elements 225 may be associated with the code in the store 220.
• the metadata injector 205 represents code that may call the interface 210 and provide metadata.
• the metadata injector 205 may include an instruction of code that is being executed in a managed runtime environment.
• the code may call the metadata manager 215 through the interface 210 and may provide one or more parameters that correspond to the parameters previously mentioned.
• the metadata injector 205 may also include other components that provide data to the metadata manager 215.
• the metadata injector 205 may include the managed runtime environment in which the code executes.
• the managed runtime environment may, for example, provide scope information to the metadata manger 215.
• the interface 210 may comprise a programming interface that allows
• the metadata manager 215 may comprise a component that stores metadata in the metadata store 221 and also stores associations between the metadata and the logical elements 225.
• the metadata manager 215 may store the metadata in a memory of a managed runtime environment by setting attributes associated with the runtime. When the attributes are manipulated, the behavior of the managed runtime environment may be modified.
• the metadata manager 215 may also provide metadata from the metadata store 221 to a requestor upon receiving an identifier of the metadata requested.
• the metadata manager 215 may call code (e.g., callback code), examine runtime state, or perform other actions as needed to calculate the metadata.
• FIG. 3 is a block diagram that illustrates exemplary components that may interact with each other in accordance with aspects of the subject matter described herein.
• the system 300 may include a metadata provider 305, a metadata consumer 310, a context provider 315, a metadata manager 320, a store 325, and other components (not shown).
• the metadata provider 305 includes any component operable to provide metadata in response to evaluating an instruction of code.
• Some examples of the metadata provider include: a program executing in a managed runtime environment, a software development tool, a managed runtime environment, an operating system, and the like.
• the metadata provider 305 may be accessed by an API by which code executing in the managed runtime environment may provide metadata and data associated with the metadata to the metadata manager 320.
• the metadata provider 305 may provide an identifier and a payload to the metadata manager 320.
• the metadata provider 305 may also provide other data to the metadata manager 320 in the form of one or more parameters as has been indicated previously.
• the metadata provider 305 may explicitly provide an identifier of a logical element to the metadata manager 320.
• the identifier of a logical element may be implicitly provided via the context provider 315.
• the context provider 315 may determine the identifier of the logical element based on a scope of an executed instruction that calls the metadata manager 320. The context provider 315 may then pass this identifier to the metadata manager.
• a function A may be called by functions B, C, D, and so forth.
• a grouping identifier e.g., "ParentlsB" or "ParentlsNotB”
• the metadata manager 320 may be provided to and stored by the metadata manager 320.
• This data may then be used by the metadata consumer 310 to obtain additional helpful information.
• a profiler may be interested in calls from B to the function A but may not be interested in calls to the function A from other functions.
• the profiler may query the metadata manager 320 using the grouping identifier as a qualifier.
• the metadata manager 320 is operable to receive the identifiers indicated above and a payload.
• the identifiers may together form lookup data that may be used to obtain the payload from the store 325.
• Lookup data may include the identifiers or be data that is derived (e.g., through a function) from the identifiers.
• the payload may include one or more of: metadata, code that when executed computes the metadata, and a reference to code that when executed computes the metadata.
• the store 325 may include any storage media capable of storing metadata together with the lookup data and may be implemented in a manner similar to the implementation of the store 150 of FIG. 1.
• the metadata consumer 310 is any component that requests metadata from the metadata manager 320 and may include, for example, the types of components indicated above with respect to the metadata provider 305.
• the metadata consumer 310 may provide one or more identifiers to the metadata manager 320 and may receive metadata in response thereto.
• FIGS. 4-5 are flow diagrams that generally represent exemplary actions that may occur in accordance with aspects of the subject matter described herein.
• the methodology described in conjunction with FIGS. 4-5 is depicted and described as a series of acts. It is to be understood and appreciated that aspects of the subject matter described herein are not limited by the acts illustrated and/or by the order of acts. In one embodiment, the acts occur in an order as described below. In other embodiments, however, the acts may occur in parallel, in another order, and/or with other acts not presented and described herein. Furthermore, not all illustrated acts may be required to implement the methodology in accordance with aspects of the subject matter described herein. In addition, those skilled in the art will understand and appreciate that the methodology could alternatively be represented as a series of interrelated states via a state diagram or as events.
• FIG. 4 is a flow diagram that generally represents exemplary actions that may occur in obtaining and storing metadata in accordance with aspects of the subject matter described herein. At block 405, the actions begin.
• code is loaded into a memory of a managed runtime environment.
• the runtime manager 120 may load code from the store 150 into main memory in preparation for executing the code.
• an instruction of the code is evaluated.
• the runtime manager 120 may evaluate an instruction of the code that was loaded into main memory.
• the instruction may include a statement that is to be executed or may be embedded in a comment that is not normally executed.
• a metadata identifier is obtained.
• the metadata manager 215 may obtain a metadata identifier from the metadata injector 205.
• the metadata identifier may be received explicitly from the metadata provider 305 or implicitly from the context provider 315.
• this may, for example, involve determining a logical element that includes the instruction that provides the metadata identifier. Determining a logical element may, for example, include actions by the runtime including finding a topmost stack frame, creating a data structure to represent a specific call, or the like.
• a logical element identifier is obtained.
• the metadata manager 320 may obtain the logical element identifier explicitly from the metadata provider 305 or implicitly from the context provider 315.
• the identifiers and the payload are stored.
• the metadata manager 320 may store the metadata identifier and the logical element identifier together with the payload in the store 325.
• the runtime may modify debugging, profiling, or other behavior based on the metadata.
• other data about the metadata may be received such as, for example, an applies-to parameter, a parameter that indicates a maximum number of times the instruction is allowed to be used to set the metadata before removing the instruction from the code, a parameter that indicates a level of recursion to associate with the metadata, an indication of inheritance that indicates whether the metadata is to be inherited to children of the logical element, any other data previously mentioned, and the like.
• FIG. 5 is a flow diagram that generally represents exemplary actions that may occur from a metadata manager's perspective in accordance with aspects of the subject matter described herein. At block 505, the actions begin.
• identifiers and a payload are received in response to a managed runtime environment executing an instruction of user code.
• the metadata manager 320 may receive identifiers from the metadata provider 305 and the context provider 315 and may receive a payload from the metadata provider 305.
• the identifiers and payload are maintained in a store.
• the metadata manager 320 may cause the identifiers and the payload to be stored in the store 325.
• Metadata and the application of metadata be coupled together.
• the metadata identifier e.g., setUserUnhandledException
• metadata and application of the metadata may be decoupled.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Hardware Design (AREA)
• Quality & Reliability (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=49083768

Family Applications (1)

Country Status (4)

Families Citing this family (5)

Family Cites Families (24)

• 2012
  • 2012-08-16 US US13/586,896 patent/US9135034B2/en active Active
• 2013
  • 2013-08-15 WO PCT/US2013/055218 patent/WO2014028784A1/en active Application Filing
  • 2013-08-15 CN CN201380043599.0A patent/CN104583970B/zh active Active
  • 2013-08-15 EP EP13753954.0A patent/EP2885712B1/de active Active

Non-Patent Citations (2)

Also Published As

Similar Documents

Legal Events