Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A set of optimizations may be defined in a configuration database. The
configuration database may be defined with a set of boundaries that may
define conditions under which the optimizations may be valid. When the
conditions are not met, a new configuration database may be requested
from an optimization server. The system may be used to distribute and
manage optimizations for an application, which may be deployed in
interpreted or runtime scenarios or in pre-execution or compiled
scenarios.

Claims:

1. A method performed by a computer processor, said method comprising:
receiving an application; receiving a configuration database for said
application, said configuration database comprising operational
boundaries for said configuration database; executing said application
with said configuration database; determining that at least one of said
operational boundaries has been exceeded, sending a request to a
distribution server, and receiving an updated configuration database; and
executing said application with said updated configuration database.

2. The method of claim 1 further comprising: determining a first state;
and transmitting said first state to said distribution server prior to
receiving said configuration database.

3. The method of claim 2, said request comprising a second state.

4. The method of claim 3 further comprising: compiling said application
and referencing said configuration database during said compiling.

5. The method of claim 3 further comprising: interpreting said
application and referencing said configuration database during said
interpreting.

6. The method of claim 3, said first state comprising an external input.

7. The method of claim 6, said external input comprising at least one of
a group composed of: hardware configuration; software configuration; time
limitation; and geographic limitations.

8. The method of claim 3, said first state comprising an application
input.

9. The method of claim 8, said operational boundary defining a range for
said application input.

10. The method of claim 1, said configuration database being a
configuration file.

11. The method of claim 10, said configuration database being used with a
compiler to generate optimized executable code.

12. The method of claim 1, said configuration database being used with an
execution environment to interpret said application.

13. A system comprising: a processor; a execution monitor operating on
said processor that: receives an application; receives a configuration
database for said application, said configuration database comprising
operational boundaries for said configuration database; executes said
application with said configuration database; determines that at least
one of said operational boundaries has been exceeded, sending a request
to a distribution server, and receiving an updated configuration
database; and executes said application with said updated configuration
database.

14. The system of claim 13 further comprising: a compiler that accesses
said configuration database to create optimized executable code.

15. The system of claim 13 further comprising: an execution environment
that accesses said configuration database during runtime execution of
said application.

16. The system of claim 13, said request comprising a first state.

17. The system of claim 13, said first state comprising an external
input.

18. The system of claim 17, said external input comprising at least one
of a group composed of: hardware configuration; software configuration;
time limitation; and geographic limitations.

19. The system of claim 16, said first state comprising an application
input.

20. The system of claim 13, said operational boundary defining a range
for said application input.

Description:

BACKGROUND

[0001] Computer execution systems allocate memory to various processes
when the processes are launched. As a process executes, additional memory
may be allocated to the process or unused memory may be deallocated and
used by other processes.

[0002] Some execution systems may have garbage collection systems and
other memory management functions that may attempt to efficiently use the
memory in the system.

[0003] In many execution systems, memory allocation and management may be
designed for a general purpose application. Such systems may have a
single allocation scheme, for example, that may be applied to all
executable code.

SUMMARY

[0004] A set of optimizations may be defined in a configuration database.
The configuration database may be defined with a set of boundaries that
may define conditions under which the optimizations may be valid. When
the conditions are not met, a new configuration database may be requested
from an optimization server. The system may be used to distribute and
manage optimizations for an application, which may be deployed in
interpreted or runtime scenarios or in pre-execution or compiled
scenarios.

[0005] This Summary is provided to introduce a selection of concepts in a
simplified form that are further described below in the Detailed
Description. This Summary is not intended to identify key features or
essential features of the claimed subject matter, nor is it intended to
be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In the drawings,

[0007] FIG. 1 is a diagram illustration of an embodiment showing a system
with offline optimization for memory allocation and management.

[0008] FIG. 2 is a diagram illustration of an embodiment showing a device
with an execution environment that may use a configuration file for
memory allocation and management.

[0009] FIG. 3 is a flowchart illustration of an embodiment showing
interactions of components for offline optimization.

[0010] FIG. 4 is a flowchart illustration of an embodiment showing a
method for executing a target application with a configuration file.

[0011] FIG. 5 is a diagram illustration of an embodiment showing a
mechanism for decorating compiled code.

[0012] FIG. 6 is a flowchart illustration of an embodiment showing a
method for decorating compiled code.

[0013] FIG. 7 is a flowchart illustration of an embodiment showing a
method for executing decorated code.

[0014] FIG. 8 is a flowchart illustration of an embodiment showing a
method for interacting with a configuration file with a boundary
definition.

DETAILED DESCRIPTION

[0015] A software execution system may use a configuration file to define
various memory allocation and garbage collection parameters. The system
may be able to apply different memory allocation and management
parameters to individual applications, processes, and functions, which
may be known as managed entities. Each managed entity may have an entry
in the configuration file, and when the entity performs a memory
allocation operation, the configuration file may be queried to determine
or derive the corresponding parameters.

[0016] The system may use offline analysis to generate the configuration
file, then distribute the configuration file to multiple devices that
execute a particular application or set of applications. Operational data
may be collected from instrumented versions of an execution system and
transmitted to a remote optimization system. The remote optimization
system may generate the configuration file and distribute the
configuration file to devices that may execute the application with a
non-instrumented version of the execution system. In some cases, the
configuration file may be used with a lightly instrumented execution
system or one in which the instrumentation may be minimized.

[0017] The remote optimizer may determine an optimized set of memory
configuration parameters by analyzing data gathered from many
instrumented systems. In some cases, the remote optimizer may analyze
data from differently configured computer systems, such as systems with
different hardware, different operating systems, different configurations
of operating systems, different additional applications, and other
differences.

[0018] The remote optimizer may identify certain states in which a set of
configuration parameters may be valid. The state definition may include
static state information, such as hardware and software configuration, as
well as dynamic state information, such as the amount of available memory
and the state of other applications running on the system. The
combination of static and dynamic state information may be included in a
configuration file to identify the appropriate state for specific
settings.

[0019] Throughout this specification and claims, the term "configuration
file" is used to denote a database that may be consumed by an execution
environment. In some cases, the "configuration file" may be an actual
file managed within an operating system's file system, but in other
cases, the "configuration file" may be represented as some other form of
database that may be consumed by the execution environment. The term
"configuration file" is used as convenient description for the purposed
of this specification and claims, but is not meant to be limiting.

[0020] In many embodiments, data may be collected when the target
executable code is run to determine dynamic and operational monitored
parameters. Monitored parameters collected from the target code may not
include any personally identifiable information or other proprietary
information without specific permission of the user. In many cases, many
optimized configurations may be generated without knowledge of the
workload handled by the executable code.

[0021] In the case where the monitoring occurs in an execution environment
such as an operating system or virtual machine, the monitoring may
collect operating system and virtual machine performance data without
examining the application or other workload being executed. In the case
where the monitoring occurs within an application, the monitoring may
collect operational and performance data without collecting details about
the input or output of the application.

[0022] In the case when data may be collected without an agreement to
provide optimization, the collected data may be anonymized, summarized,
or otherwise have various identifiable information removed from the data.

[0023] Throughout this specification, like reference numbers signify the
same elements throughout the description of the figures.

[0024] When elements are referred to as being "connected" or "coupled,"
the elements can be directly connected or coupled together or one or more
intervening elements may also be present. In contrast, when elements are
referred to as being "directly connected" or "directly coupled," there
are no intervening elements present.

[0025] The subject matter may be embodied as devices, systems, methods,
and/or computer program products. Accordingly, some or all of the subject
matter may be embodied in hardware and/or in software (including
firmware, resident software, micro-code, state machines, gate arrays,
etc.) Furthermore, the subject matter may take the form of a computer
program product on a computer-usable or computer-readable storage medium
having computer-usable or computer-readable program code embodied in the
medium for use by or in connection with an instruction execution system.
In the context of this document, a computer-usable or computer-readable
medium may be any medium that can contain, store, communicate, propagate,
or transport the program for use by or in connection with the instruction
execution system, apparatus, or device.

[0026] The computer-usable or computer-readable medium may be, for example
but not limited to, an electronic, magnetic, optical, electromagnetic,
infrared, or semiconductor system, apparatus, device, or propagation
medium. By way of example, and not limitation, computer readable media
may comprise computer storage media and communication media.

[0027] Computer storage media includes volatile and nonvolatile, removable
and non-removable media implemented in any method or technology for
storage of information such as computer readable instructions, data
structures, program modules or other data. Computer storage media
includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other
memory technology, CD-ROM, digital versatile disks (DVD) or other optical
storage, magnetic cassettes, magnetic tape, magnetic disk storage or
other magnetic storage devices, or any other medium which can be used to
store the desired information and which can accessed by an instruction
execution system. Note that the computer-usable or computer-readable
medium could be paper or another suitable medium upon which the program
is printed, as the program can be electronically captured, via, for
instance, optical scanning of the paper or other medium, then compiled,
interpreted, of otherwise processed in a suitable manner, if necessary,
and then stored in a computer memory.

[0028] When the subject matter is embodied in the general context of
computer-executable instructions, the embodiment may comprise program
modules, executed by one or more systems, computers, or other devices.
Generally, program modules include routines, programs, objects,
components, data structures, etc. that perform particular tasks or
implement particular abstract data types. Typically, the functionality of
the program modules may be combined or distributed as desired in various
embodiments.

[0029] FIG. 1 is a diagram of an embodiment 100 showing a system with
remote analysis and optimization for memory allocation. Embodiment 100
illustrates a generic workflow where instrumented systems may collect
tracing data that is analyzed by an optimizer to create a configuration
database. The configuration database, sometimes referred to as a
configuration file, may be consumed by other devices.

[0030] The system may collect data from many different devices that
execute an application or other workload under many different
circumstances. These devices 102 and 104 may each have an instrumented
environment which executes an application. In the example of embodiment
100, device 102 is illustrated as having an instrumented environment 106
and running application 108 and device 104 is illustrated as having an
instrumented environment 110 running application 112. In both cases, the
application 108 and 112 may be the same application.

[0031] The instrumented environments 106 and 110 may collect and transmit
tracing data 114. The tracing data 114 may include static and dynamic
data regarding the execution of an application. The static data may
include various environmental descriptors that may describe the hardware
and software comprising the devices, while the dynamic data may relate to
the execution of the application.

[0032] The static data may include environmental descriptors such as the
operating system, user, location, as well as other applications,
services, and software either running or available on the device. Such
data may be considered `static` in the sense that the data may not change
during the execution of a target application.

[0033] The dynamic data may include any value that may change during
execution. For example, dynamic data may include tracing information that
may track the operations of each function, process, thread, or other
executable element. The tracing data may include information regarding
each memory allocation event or boundary, such as how much memory is
available, how much memory is allocated as a result of the event, and
other information. The tracing data may also include the function,
process, thread, or other component that caused the memory allocation
boundary, as well as any values, variables, or other information
available, such as values passed to the component or information in a
call stack, for example.

[0034] In many cases, a snapshot of certain variables may be made at
regular intervals or when specific events occur. The snapshots may
include information about the state of executing software, such as the
number and identify of functions, processes, threads, or other components
currently in execution, as well as any components that may be awaiting
execution.

[0035] In embodiments where data being processed by an application may be
collected, the data may be anonymized, scrubbed, or otherwise processed
to remove personally identifiable or other sensitive information. Such
data may be collected when a user has expressly granted permission for
collection.

[0036] The tracing data 114 may be collected from many different devices
that execute the same application in different conditions. In some cases,
the diversity of data sources may lead to a more reliable optimization.

[0037] The output of the optimizer 116 may be a configuration database 118
that may be consumed by the computer systems 120, 122, and 124. The
computer system 120 is shown with an execution environment 126 and
configuration file 128 and application 130. Computer system 122 is shown
with an execution environment 132 and configuration file 134 and
application 136. Similarly, computer system 124 is shown with an
execution environment 138, a configuration file 140, and an application
142.

[0038] The configuration database 118 may be distributed to various client
computers 120, 122, and 124 that may or may not have contributed data to
the tracing data 114. In some cases, a small sample of instrumented
computer systems 102 and 104 may create the tracing data 114 from which
the configuration database 118 is generated. The configuration database
118 may then be used by a different set of computers 120, 122, and 124.

[0039] In one use scenario, a set of instrumented systems may execute an
application under a wide variety of conditions to generate tracing data
114. The conditions may be test conditions or other conditions so that an
application may be extensively exercised. The resulting configuration
database 118 may then be used by multiple client computer systems 120,
122, and 124 to execute a production version of the application in an
optimized manner.

[0040] For example, the target application may be an application that may
receive API calls and return a value. The application may be run under
test conditions to exercise all possible inputs or requests. During such
testing, tracing data may be collected and optimized to generate a
configuration database.

[0041] The optimized configuration in the configuration database 118 may
be any representation of an optimized configuration. In some cases, an
optimized configuration may be a constant value or set of constant values
that may be applied at a memory allocation boundary. In other cases, the
optimized configuration may be a function or expression, which may be
expressed in executable code or other expression.

[0042] FIG. 2 is a diagram of an embodiment 200 showing a client computer
system with a system with a configuration file. Embodiment 200
illustrates hardware components that may create, deliver, and consume
optimized configuration information.

[0043] The diagram of FIG. 2 illustrates functional components of a
system. In some cases, the component may be a hardware component, a
software component, or a combination of hardware and software. Some of
the components may be application level software, while other components
may be execution environment level components. In some cases, the
connection of one component to another may be a close connection where
two or more components are operating on a single hardware platform. In
other cases, the connections may be made over network connections
spanning long distances. Each embodiment may use different hardware,
software, and interconnection architectures to achieve the functions
described.

[0044] Embodiment 200 illustrates a device 202 that may have a hardware
platform 204 and various software components. The device 202 as
illustrated represents a conventional computing device, although other
embodiments may have different configurations, architectures, or
components.

[0045] In many embodiments, the optimization server 202 may be a server
computer. In some embodiments, the optimization server 202 may still also
be a desktop computer, laptop computer, netbook computer, tablet or slate
computer, wireless handset, cellular telephone, game console or any other
type of computing device.

[0046] The hardware platform 204 may include a processor 208, random
access memory 210, and nonvolatile storage 212. The hardware platform 204
may also include a user interface 214 and network interface 216.

[0047] The random access memory 210 may be storage that contains data
objects and executable code that can be quickly accessed by the
processors 208. In many embodiments, the random access memory 210 may
have a high-speed bus connecting the memory 210 to the processors 208.

[0048] The nonvolatile storage 212 may be storage that persists after the
device 202 is shut down. The nonvolatile storage 212 may be any type of
storage device, including hard disk, solid state memory devices, magnetic
tape, optical storage, or other type of storage. The nonvolatile storage
212 may be read only or read/write capable. In some embodiments, the
nonvolatile storage 212 may be cloud based, network storage, or other
storage that may be accessed over a network connection.

[0049] The user interface 214 may be any type of hardware capable of
displaying output and receiving input from a user. In many cases, the
output display may be a graphical display monitor, although output
devices may include lights and other visual output, audio output, kinetic
actuator output, as well as other output devices. Conventional input
devices may include keyboards and pointing devices such as a mouse,
stylus, trackball, or other pointing device. Other input devices may
include various sensors, including biometric input devices, audio and
video input devices, and other sensors.

[0050] The network interface 216 may be any type of connection to another
computer. In many embodiments, the network interface 216 may be a wired
Ethernet connection. Other embodiments may include wired or wireless
connections over various communication protocols.

[0051] The client 202 may have an operating system 218 that may execute
various applications 232 and function as an execution environment. As an
execution environment, the operating system 218 may have an execution
monitor 220 which may detect when memory allocation boundaries occur,
consult a configuration file 222, and allocate and manage memory in a
different manner when an entry exists in the configuration file 222.

[0052] In some embodiments, a virtual machine 224 may operate as an
execution environment. As such, the virtual machine 224 may contain an
execution monitor 226 which may detect a memory allocation boundary,
consult a configuration file 228, and allocate and manager memory in a
different manner when an entry exists in the configuration file 228.

[0053] The virtual machine 224 may be a process virtual machine or other
environment that manages execution of applications 232. Such environments
may allocate memory, perform garbage collection, as well as other memory
management tasks.

[0054] An execution environment, whether it is a virtual machine 224 or
operating system 218, may capture memory allocation events or boundaries,
then apply special handling to the memory when the event may be found in
a configuration file. In many cases, the configuration file may include
parameters, descriptors, or other information that may be used by the
execution environment to allocate and manage memory.

[0055] Capturing memory allocation events may be done in a passive manner
by monitoring the execution of an application and detecting that a memory
allocation boundary has been breached. Once detected, a lookup may be
performed against a configuration file, and the configuration file may
include parameters, indicators, or other information that may be consumed
by the execution environment.

[0056] In some embodiments, the memory allocation events may be identified
by decorations added to the application. For example, those memory
allocation events for which an entry exists in a configuration file may
have code or other decorations added to the application at each memory
allocation event. The decorations may be identified by an execution
monitor and the lookup performed against the configuration file. In some
cases, the decorations may be executable code or merely flags or other
annotations that may be processed by an execution monitor.

[0057] A distribution client 230 may receive configuration files 222 and
228 from a remote optimization server 236. The distribution client 230
may be an application that may interact with the remote optimization
server 236 in different manners depending on the embodiment. Some
embodiments may subscribe to a feed provided by the remote optimization
server 236, while other embodiments may poll the remote optimization
server 236 and periodically request updates to a configuration file.
Other embodiments may push changes from the remote optimization server
236 to the distribution client 230.

[0058] A network 234 may connect the client 202 to the remote optimization
server 236, which may be connected to various collection clients 248. The
remote optimization server 236 may collect tracing and performance data
from the collection clients 248 and determine an optimized configuration
file for specific applications.

[0059] The remote optimization server 236 may have a hardware platform 238
on which an optimizer 240 may execute. The optimizer 240 may create
configuration files from a performance database 246 that contains trace
data and other information collected from the various collection clients
248. A data collector 242 may interact with the collection clients 248 to
gather the performance data.

[0060] A distribution system 244 may manage the configuration files and
transmit the configuration files to client devices, such as the client
202.

[0061] The collection clients 248 may contain a hardware platform 250 on
which an instrumented execution environment 252 may execute applications
256. During the execution, the instrumented execution environment 252 may
collect tracing data, state data, and other information that may be
transmitted to the remote optimization server 236 by a data collector
client 254.

[0062] In some embodiments, the collection clients 248 may have a
configuration file 258. The configuration file 258 may be used in two
scenarios.

[0063] In a first scenario, the configuration file 258 may be an optimized
configuration that may be generated by the remote optimization server
236. In such a scenario, the collection clients 248 may continue to
collect performance data after the optimized configuration file has been
generated. Such an operation may collect information that may verify or
further tune the configuration file in an iterative process.

[0064] In a second scenario, the configuration file 258 may be populated
at least in part by the instrumented execution environment 252. In one
version of such a scenario, the instrumented execution environment 252
may identify memory allocation boundaries and create records for the
boundaries in the configuration file 258. The configuration file 258 may
be transmitted to the remote optimization server 236 and the remote
optimization server 236 may populate the configuration file with a set of
optimized values for each memory allocation boundary.

[0065] In another version of such a scenario, the instrumented execution
environment 252 may perform some or all of the optimizations. For
example, the instrumented execution environment 252 may identify a memory
allocation boundary, determine an optimized setting, and store the
optimized setting in the configuration file 258.

[0066] FIG. 3 is a flowchart illustration of an embodiment 300 showing
interactions between an instrumented environment 302, an optimizer 304,
and a runtime environment 306. The operations of the instrumented
environment 302 are shown in the left hand column, while the operations
of the optimizer 304 are shown in the center column and the operations of
the runtime environment 306 are shown in the right hand column.

[0067] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0068] Embodiment 300 illustrates a system where data may be collected
from a set of heavily instrumented systems, and optimized to create a
configuration file that may be consumed by a runtime system. The runtime
system may perform a lightweight data collection which may be fed back to
the optimizer.

[0069] The instrumented environment 302 may begin executing target code in
block 308. The state of the system may be collected in block 310, and
instrumentation data may be collected in block 312. The data may be
transmitted to the optimizer 304 in block 314.

[0070] In many embodiments, multiple instrumented environments may collect
data. Each system that collects data may provide state data for that
system. The state data may define various static and dynamic
characteristics of the hardware, software, and target application.

[0071] The optimizer 304 may receive data in block 316 and determine
optimized settings in block 318. The optimized settings in block 318 may
define various characteristics about memory handling, including memory
allocation settings for initial and subsequent allocation events, garbage
collection settings and options, and other parameters.

[0072] A configuration database may be defined in block 320. The
configuration database, sometimes referred to as a configuration file,
may contain identifiers for memory allocation boundaries for which
optimized memory handling may be defined.

[0073] The configuration database may be distributed in block 322 by the
optimizer 304 and received by the runtime environment 306 in block 324.

[0074] The runtime environment 306 may execute the target application with
the optimized configuration in block 326. While the code is executing in
the optimized mode, lightweight data collection may be performed in block
328. The collected data may be transmitted in block 330 to the optimizer
304, which may collect the data in block 332 and iterate on the newly
received data. Meanwhile, the runtime environment 306 may continue
executing the target application in block 326.

[0075] FIG. 3 is a flowchart illustration of an embodiment 300 showing
interactions between an instrumented environment 302, an optimizer 304,
and a runtime environment 306. The operations of the instrumented
environment 302 are shown in the left hand column, while the operations
of the optimizer 304 are shown in the center column and the operations of
the runtime environment 306 are shown in the right hand column.

[0076] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0077] FIG. 4 is a flowchart illustration of an embodiment 400 showing a
method for executing with a configuration file. Embodiment 400 may
represent a method performed by an execution environment which may
execute with a configuration file and modify memory allocation and
management settings when a memory allocation boundary is defined in a
configuration file.

[0078] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0079] Embodiment 400 may represent an embodiment where memory allocation
boundaries may be captured and acted upon when the boundary may be found
in a configuration file. The operations of embodiment 400 may be
performed with interpreted or compiled code. In some embodiments, the
code may be decorated prior to execution to aid in identifying memory
allocation boundaries for which customized treatment may be implemented.
In such embodiments, the identification of memory allocation boundaries
may be performed at compile time and acted upon during execution.

[0080] A configuration file may be received in block 402, and target
executable code may be received in block 404.

[0081] A global state for the system may be determined in block 406. The
global state may be any parameter or other information that may define
the state of hardware, software, or other components that may affect how
the target code may execute. In some embodiments, a configuration file
may indicate for which states certain values may be applicable.

[0082] Execution of the target code may begin in block 408.

[0083] During execution, a memory allocation boundary may be captured or
identified in block 410. The execution state may be captured in block
412. Using the execution state and the memory allocation boundary, a
lookup may be performed in the configuration file in block 414.

[0084] When the memory allocation boundary is not found in the
configuration file in block 416, a memory allocation may be configured
with a set of default settings in block 418. A garbage collector may also
be configured in block 420 with a default garbage collector scheme.

[0085] When the memory allocation boundary is found in the configuration
file in block 416, the memory allocation scheme may be looked up in block
422. The memory allocation scheme may be defined in the configuration
file or other location. Using the defined scheme, the memory allocation
may be configured in block 424 and the garbage collection may be
similarly configured in block 426.

[0086] Memory may be allocated in block 428 according to the defined
scheme and garbage collection may be launched in block 430 according to
the defined scheme.

[0087] The process may return to block 410 to continue execution.

[0088] FIG. 5 is a diagram illustration of an embodiment 500 showing the
creation of decorated code. Embodiment 500 illustrates how a
configuration database may be used during compilation to annotate,
decorate, or otherwise modify source code prior to execution.

[0089] Source code 502 may be compiled by a compiler 504. During
compilation, an examination of each memory allocation boundary may be
performed. When a memory allocation boundary may be found in a
configuration database 506, the code may be decorated to produce
decorated compiled code 510.

[0090] The decorated compiled code 510 may be consumed by the runtime
environment 512.

[0091] An optimizer 508 may produce the configuration database 506. In
some cases, the optimizer 508 may consume tracing code that may be
generated by interpreted or compiled code, but the configuration database
506 may be consumed by compiled code.

[0092] The decorations performed during compiling may be merely flagging a
memory allocation boundary that a record may exist. In such an
embodiment, the runtime environment 512 may attempt to look up the memory
allocation boundary in the configuration database 506.

[0093] In other embodiments, the decorations may include adding
instructions to the decorated compiled code 510 that perform a lookup
against the configuration database 506.

[0094] In still other embodiments, the decorations may include information
from the configuration database 506 that may be used by the runtime
environment 512. In such embodiments, the runtime environment 512 may not
query the configuration database 506.

[0095] The source code 502 may be human readable source code which may
produce intermediate code or machine executable code. In some cases, the
source code 502 may be intermediate code that may be compiled to machine
executable code.

[0096] The compiler 504 may be a just-in-time compiler that may perform
compilation at runtime in some embodiments.

[0097] FIG. 6 is a flowchart illustration of an embodiment 600 showing a
method for decorating compiled code. Embodiment 600 may represent the
operations of a compiler, such as compiler 504 in embodiment 500.

[0098] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0099] Embodiment 600 may process source code during compilation to
identify memory access boundaries and decorate the compiled code with
annotations regarding how memory may be handled. The decorations may be
hooks or identifiers that may be processed by a runtime environment. In
some cases, the decorations may be executable code or parameters that may
cause memory management to occur according to a configuration database.

[0100] Source code may be received in block 602. The source code may be
human readable source code, intermediate code, or other code that may be
compiled.

[0101] The configuration database may be received in block 604.

[0102] Compilation may be performed in block 606.

[0103] If a memory allocation boundary is not detected in block 608 and
the compiling has not completed, the process loops back to block 606.
When the compiling has completed in block 610, the compiled code may be
stored in block 612.

[0104] When a memory allocation boundary is detected in block 608, the
memory allocation boundary may be looked up in the configuration file in
block 614. When there is no match in block 616, the process may return to
block 610. When there is a match, the compiled code may be decorated in
block 618.

[0105] In some embodiments, the decorations may be executable commands,
sequences, or other code that cause the memory allocation boundary to be
handled according to the configuration database. Such embodiments may not
perform a look up to the configuration database at runtime. In other
embodiments, the decorations may include executable code that performs a
look up a configuration database. In still other embodiments, the
decorations may be identifiers that may assist a runtime environment in
identifying a memory allocation boundary that may have an entry in the
configuration database.

[0106] FIG. 7 is a flowchart illustration of an embodiment 700 showing a
method for executing decorated code. Embodiment 700 may illustrate the
operations of a client device that executes code that may have been
created by the process of embodiment 600.

[0107] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0108] Embodiment 700 illustrates a method by which decorated code may be
executed. In some cases, the decorated code may be compiled code that may
contain decorations or additions to the code at places where memory
allocation may occur. In other cases, the decorated code may be
interpreted code to which decorations may have been added.

[0109] The executable code may be received in block 702 and may begin
executing in block 704.

[0110] During execution, a memory allocation boundary may be detected in
block 706. If the memory allocation boundary is not decorated in block
710, a default set of memory allocation settings may be used in block 710
and the process may return to block 704.

[0111] If the memory allocation boundary is decorated in block 710, the
decoration may be evaluated to determine how to allocate memory. In some
cases, the decoration may fully define how the memory allocation may
proceed. When the decoration completely defines allocation settings in
block 712, those allocation settings may be used in block 714.

[0112] In other cases, the decoration code may be executed in block 716 to
determine the allocation settings. In some cases, a lookup may be
performed in block 718. In some cases, the decoration code may define a
calculation that may be performed in block 720. The newly determined
allocation settings may be used in block 722 to perform the allocation
operation.

[0113] FIG. 8 is a flowchart illustration of an embodiment 800 showing a
method for interacting with a configuration file with a boundary
definition. The method of embodiment 800 may illustrate a configuration
file that includes boundaries. The operations of a client device with a
runtime environment 802 are illustrated on the left hand column, and the
operations of an optimization server 804 may be shown in the right hand
column.

[0114] Other embodiments may use different sequencing, additional or fewer
steps, and different nomenclature or terminology to accomplish similar
functions. In some embodiments, various operations or set of operations
may be performed in parallel with other operations, either in a
synchronous or asynchronous manner. The steps selected here were chosen
to illustrate some principles of operations in a simplified form.

[0115] Embodiment 800 may illustrate the interaction of a client system
and an optimization server. The configuration file consumed by the
runtime environment 802 may include boundaries or limits that the client
system may monitor. When those boundaries are exceeded, the client system
may requests an updated configuration file.

[0116] The boundaries in the configuration file may define any limit or
boundary for the configuration file. In some cases, the boundaries may
include parameters associated with the application. Such boundaries may
include parameter values for which a given optimization may be valid,
ranges for internal memory objects, or other limits. Such limits may
define the range of values from which optimization parameters have been
derived or tested. In many cases, parameters outside of the boundaries
may cause the client system to operate in a non-optimal manner.

[0117] The boundaries may define external inputs to the application, which
may include the state of the system on which the application executes.
The state may include hardware and software configuration, geographic
limitations, or other items.

[0118] The hardware configuration may include processor configuration,
memory configuration, presence or absence of various peripheral devices.
The software configuration may include operating system version and
configuration, presence or absence of other applications, services,
databases, or other components.

[0119] The boundaries may include time limitations or other limitations on
execution. For example, a boundary may define a time period for which the
configuration file may be valid. In one example, the time period may
indicate an expiration date after which the configuration file may not be
used. Such an indicator may be part of a business model in which a
customer pay purchase optimization services on a subscription basis.

[0120] The boundaries may include geographic boundaries, such as
jurisdictional boundaries, for which the configuration file may be valid.
The geographic boundaries may be contractual limitations for which an
optimization service may be purchased.

[0121] A time period may reflect a recurring or periodic nature of an
optimization. For example, a configuration file may be valid during a
period of high use, which may be during regular business hours, but a
different configuration file may be used in the evenings or overnight
during backup and administrative activities. In another example, a
configuration file for an application in a retail consumer business may
be valid during a holiday season but not valid afterwards.

[0122] The boundaries may define application inputs for which a
configuration file may be valid. The boundaries may define ranges of
valid input parameters or other input definition. In some cases, the
ranges may reflect data for which optimizations have been calibrated or
tested, and the ranges may reflect values for which the optimizations may
be known to be invalid or harmful.

[0123] In block 806, a runtime environment 802 may capture a current state
and may transmit the state in block 808 to the optimization server 804,
which may receive the state in block 810.

[0124] The optimization sever 804 may determine optimization settings for
the current state in block 812, determine boundaries for the optimization
settings in block 814, and create a configuration file with the boundary
definition in block 816.

[0125] The configuration file may be transmitted in block 818 from the
optimization server 804 and received in block 820 by the runtime
environment 802.

[0126] The runtime environment 802 may execute the corresponding
application with the configuration file in block 822. During execution,
the boundaries may be checked in block 824. Provided that the boundaries
are met in block 826, the process may loop back to block 822.

[0127] When the boundary may be exceeded in block 826, the process may
loop back to block 806, where the runtime environment 802 may capture a
new state and request a new configuration file from the optimization
server 804.

[0128] The foregoing description of the subject matter has been presented
for purposes of illustration and description. It is not intended to be
exhaustive or to limit the subject matter to the precise form disclosed,
and other modifications and variations may be possible in light of the
above teachings. The embodiment was chosen and described in order to best
explain the principles of the invention and its practical application to
thereby enable others skilled in the art to best utilize the invention in
various embodiments and various modifications as are suited to the
particular use contemplated. It is intended that the appended claims be
construed to include other alternative embodiments except insofar as
limited by the prior art.