Abstract: Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards garbage collection for an application running on a non-cooperative target platform. Where the garbage collection optimistically manages thread state for transitions to and from native and managed code and that some threads are suspended while others are left executing during garbage collection. When a characteristic of the native code call indicates that a duration of the native code call may exceed a defined duration, state information for the thread may be updated to transition the thread to the unmanaged code environment. When a garbage collection event occurs, thread state information is updated to communicate suspend requests to the threads. Then the runtime may wait for each thread in the managed code environment to be reach a safe state before garbage collection may commence.

Abstract: Embodiments are directed towards embodiments are directed towards managing parameter types for generic functions. During ahead-of-time (AOT) compilation of an application one or more generic functions may be encountered during compilation of the application. The AOT compiler may generate machine code for the encountered generic function. If parameter types associated with the encountered generic function are indefinite the AOT compiler may generate machine code that normalizes each parameter of the encountered generic function to conform to a shared version of the encountered generic function. Machine code may be generated for calling the shared version of the generic function with the normalized parameters. Machine code for calling the shared version of the generic function may be inserted and/or placed inside the machine code for the encountered generic function and inserted into a machine code version of the application.

Abstract: Embodiments are directed towards managing memory for an application be executing in a managed runtime environment. Managed peer objects may be generated to correspond to native objects executing in a native runtime environment such that memory may be allocated for managed peer objects. Garbage collection handles may be generated and associated with the managed peer objects. If the managed application executes instructions that interact with the managed peer objects and the native runtime environment each garbage collection handle associated with the managed peer objects may be modified based on a type of an interaction. The garbage collection handlers may be garbage collection roots for a garbage collector that may be included in the managed runtime memory manager. If a garbage collection event occurs, memory for the managed peer objects may be deallocated based in part on its correspondent garbage collection handle.

Abstract: Embodiments are directed towards managing generic objects across multiple runtime environments. If a generic type definition is encountered during compilation of an application it may be determined if the encountered generic type has interactions with the native runtime environment. Native runtime signatures that may be arranged to enable native objects to execute the generic type methods may be generated for each generic type methods that interact with the native runtime. Binding layer machine code may be generated to map each native runtime signature to a corresponding generic type method. And, in at least one of the various embodiments, the binding layer machine code may be inserted into the machine code version of the application.

Abstract: Embodiments are directed towards generating applications that include multi-sized types running in managed code. During the compilation of an intermediate language version of an application, if a multi-size type is encountered, a runtime engine may perform actions to process the multi-size types. Accordingly, architecture information associated with the target computer may be determined. Data types corresponding to the architecture of the target computer and the multi-sized types may be determined based on the architecture information. Native code calls associated with an intermediate language code calls may be determined such that the parameters of the native code calls match the architecture dependent data types. And, a machine code version of the intermediate language code call may be generated. The generated machine code version of the intermediate language code may be executed with the data types specific to the target computer.

Abstract: Embodiments are directed towards generating application models based on discovery based machine learning. A mobile application may be uploaded to a computer that may be part of a testing platform. A reference mobile computer may be selected and the mobile application maybe installed onto the reference mobile computer. Also, the testing platform may generate an initial application model based on the mobile application. The current active window of the mobile application may be determined and the application model may be updated accordingly. Screenshots may be generated that correspond to each current active window of the mobile application. Also, each user-interface control in the active window may be activated. The results of activating each control may be observed and added to the model. If the activation causes navigation, another active window may be determined. The application model may be used for testing other mobile computers.

Abstract: Embodiments are directed towards testing a responsiveness of a graphical user interface (GUI) for an application executing on a computer. During execution of each portion of a test, stimuli may be provided to the application. The stimuli may be provided to the application thread that is associated with rendering graphics for the GUI. Responses from the application to the stimuli may be monitored to determine a responsiveness of the application for at least one portion of the test. The responsiveness may be determined based on a wait time between providing a request and receiving a reply to the request, which may indicate that the application is in a state to accept input through the GUI. Responsiveness may be determined separately for each portion of the test. A displayable report may be generated to include the responsiveness of the application for each portion of the test.

Abstract: Embodiments are directed towards garbage collection for an application running on a non-cooperative target platform. Where the garbage collection optimistically manages thread state for transitions to and from native and managed code and that some threads are suspended while others are left executing during garbage collection. When a characteristic of the native code call indicates that a duration of the native code call may exceed a defined duration, state information for the thread may be updated to transition the thread to the unmanaged code environment. When a garbage collection event occurs, thread state information is updated to communicate suspend requests to the threads. Then the runtime may wait for each thread in the managed code environment to be reach a safe state before garbage collection may commence.

Abstract: Embodiments are directed towards generating application models based on discovery based machine learning. A mobile application may be uploaded to a computer that may be part of a testing platform. A reference mobile computer may be selected and the mobile application maybe installed onto the reference mobile computer. Also, the testing platform may generate an initial application model based on the mobile application. The current active window of the mobile application may be determined and the application model may be updated accordingly. Screenshots may be generated that correspond to each current active window of the mobile application. Also, each user-interface control in the active window may be activated. The results of activating each control may be observed and added to the model. If the activation causes navigation, another active window may be determined. The application model may be used for testing other mobile computers.

Abstract: Embodiments are directed towards testing a responsiveness of a graphical user interface (GUI) for an application executing on a computer. During execution of each portion of a test, stimuli may be provided to the application. The stimuli may be provided to the application thread that is associated with rendering graphics for the GUI. Responses from the application to the stimuli may be monitored to determine a responsiveness of the application for at least one portion of the test. The responsiveness may be determined based on a wait time between providing a request and receiving a reply to the request, which may indicate that the application is in a state to accept input through the GUI. Responsiveness may be determined separately for each portion of the test. A displayable report may be generated to include the responsiveness of the application for each portion of the test.

Abstract: Embodiments are directed towards testing mobile applications for a plurality of mobile computers. A server computer may be provided a mobile application, a test script, and mobile computer criteria. One or more mobile computers may be filtered from a larger set on the mobile computer criteria. The server computer may install the mobile application on each determined mobile computer. Next, each portion of the test script for the mobile application may be performed and/or executed on each determined mobile computer, wherein a result for each performed portion may be stored. During the test run at least one screenshot may be generated based on at least one performed portion of the test script, wherein the screenshots may be stored. The server computer may generate a displayable report that may include each screenshot and a result for each performed portion of the test script.

Abstract: Embodiments are directed towards testing mobile applications for a plurality of mobile computers. A server computer may be provided a mobile application, a test script, and mobile computer criteria. One or more mobile computers may be filtered from a larger set on the mobile computer criteria. The server computer may install the mobile application on each determined mobile computer. Next, each portion of the test script for the mobile application may be performed and/or executed on each determined mobile computer, wherein a result for each performed portion may be stored. During the test run at least one screenshot may be generated based on at least one performed portion of the test script, wherein the screenshots may be stored. The server computer may generate a displayable report that may include each screenshot and a result for each performed portion of the test script.

Abstract: Embodiments are directed towards testing a responsiveness of a graphical user interface (GUI) for an application executing on a computer. During execution of each portion of a test, stimuli may be provided to the application. The stimuli may be provided to the application thread that is associated with rendering graphics for the GUI. Responses from the application to the stimuli may be monitored to determine a responsiveness of the application for at least one portion of the test. The responsiveness may be determined based on a wait time between providing a request and receiving a reply to the request, which may indicate that the application is in a state to accept input through the GUI. Responsiveness may be determined separately for each portion of the test. A displayable report may be generated to include the responsiveness of the application for each portion of the test.

Abstract: Embodiments are directed towards testing mobile applications for a plurality of mobile computers. A server computer may be provided a mobile application, a test script, and mobile computer criteria. One or more mobile computers may be filtered from a larger set on the mobile computer criteria. The server computer may install the mobile application on each determined mobile computer. Next, each portion of the test script for the mobile application may be performed and/or executed on each determined mobile computer, wherein a result for each performed portion may be stored. During the test run at least one screenshot may be generated based on at least one performed portion of the test script, wherein the screenshots may be stored. The server computer may generate a displayable report that may include each screenshot and a result for each performed portion of the test script.