Microsoft Technology Licensing, LLC

Facebook, Inc.

Microsoft Corporation

Michael M Magruder

David L Detlefs

John Joseph Duffy

Vinod Grover

Goetz Graefe

Yosseff Levanoni

Sean Edwin Trowbridge

Raja Krishnaswamy

James S Miller

Brian M Grunkemeyer

James H Hogg

Erik B Christensen

Anders Hejlsberg

Gopala Krishna R Kakivaya

Christopher Wellington Brumme

David Bau

Brian LaMacchia

Lance Olson

Henry L Sanders

David S Ebbo

Julie D Bennett

Travis Muhlestein

Jonathan C Hawkins

Krzysztof J Cwalina

Seth Mitchell Demsey

Stefan Harrington Pharies

Christopher L Anderson

Shawn Patrick Burke

Loren Kohnfelder

Yung-Shin Lin

Anthony J Moore

Lingli Zhang

Erik B Olson

Yann Christensen

Fabio A Yeon

Jeffrey M Cooperstein

Corina Eva Feuerstein

Adam Wade Smith

Craig T Sinclair

David S Mortenson

Caleb L Doise

Alan Geoffrey Boshier

Shajan Dasan

Manish S Prabhu

Radu Rares Palanca

John I McConnell

Tarun Anand

Joseph L Roxe

Ali-Reza Adl-Tabatabai

Jan Stephen Gray

Timothy Lawrence Harris

Patrick Henri Dussud

Martin Taillefer

Vance Palmer Morrison

Gregory Darrell Fee

Weirong Zhu

Frank V Peschel-Gallee

Jason L Zander

William G Evans

Scott D Mosier

David Owen Driver

Gad Shlomo Sheaffer

Madhusudhan Talluri

Peter F Sollich

Dana D Groff

Rudi Martin

Li Zhang

Stephen Harris Toub

Yan Valerie Leshinsky

Stephen James Millet

Giovanni Moises Della-Libera

Nikhil Kothari

Martin Abadi

David S Callahan

Charles David Callahan, Ii

Scott David Guthrie

Barak Reuven Naveh

Zheng Mi

Luca Bolognese

Jonathan White Keljo

Brian Robert Crawford

Keith W Ballinger

Jonathon Michael Stall

John Lawrence Hamby

Peter A Hallam

Brian Keith Pepin

Alexander Dadiomov

Mark T Anders

Manuel Alfred Fahndrich

Jun Fang

Michael Barnett

Brian D Harry

Susan M Warren

Sam Spencer

Robert Michael Howard

Nicholas M Kramer

Manu Vasandani

John Joseph Rivard

Chad W Royal

Sean Selitrennikoff

A cluster of devices can be identified where results from executing a test by any cluster devices can be considered as being from the same device. Thus, instead of waiting for a single device to produce comparable results, multiple devices from the same cluster can simultaneously perform the test and obtain the needed set of test results more quickly. The technology can identify clusters of devices that are all similar to a primary cluster device. A device pair can be considered similar when (1) a mean each of a set of test results from each device are within a first threshold of each other, (2) a measurement of the consistency of each test result set are within a second threshold of each other, and (3) a measurement of the consistency of a combination of the test results sets is between the consistency measurements of the individual test result sets.

Dynamic device clustering

An exception handling system is described herein that provides one or more distinguished classes of software exceptions that are handled differently than other exceptions. The system treats a distinguished exception as a 'hard to catch' exception that is not passed to the catch block of program code unless a developer performs extra steps to acknowledge the distinguished nature of the exception and confirm that the program code is prepared to properly handle the exception. Exceptions that fall into this class are typically those that represent conditions from which normal exception handling practices cannot successfully recover, namely exceptions that corrupt application state. Accordingly, the system prevents the developer from catching these classes of exceptions by default unless the developer explicitly requests to have these exceptions delivered to the program code. Thus, the exception handling system encourages correct programming practices by preventing developer error by default.

Handling exceptions related to corrupt application state

An apparatus to identify and purge unused code may comprise a processor circuit on a device and a storage component configured to store a codebase including one or more portions of programming code. The apparatus may further comprise a sampling component, a profiling component, and a purge component. The sampling component may sample the codebase and generate one or more leads identifying portions of programming code from the codebase determined to be unused during a sampling period. The profiling component may receive the one or more leads and profile programming code identified therein during a profiling period and to identify portions of programming code determined to be unused during the profiling period. The purge component may receive identification of the portions of programming code determined to be unused during the profiling period and initiate a purging process thereon. Other embodiments are described and claimed.

Techniques to identify and purge unused code

Handling garbage collection and exceptions in hardware assisted transactions. Embodiments are practiced in a computing environment including a hardware assisted transaction system. A method includes beginning a hardware assisted transaction, raising an exception while in the hardware assisted transaction, including creating an exception object, determining that the transaction should be rolled back, and as a result of determining that the transaction should be rolled back, marshaling the exception object out of the hardware assisted transaction.

Efficient garbage collection and exception handling in a hardware accelerated transactional memory system

Various technologies and techniques are disclosed for supporting parallel nested transactions in a transactional memory system. Multiple closed nested transactions are created for a single parent transaction, and the closed nested transactions are executed concurrently as parallel nested transactions. Various techniques are used to ensure effects of the parallel nested transactions are hidden from other transactions outside the parent transaction until the parent transaction commits. For example, retry is allowed to work correctly with parallel nested transactions. When a transaction that is a parallel nested transaction or a child transaction of the parallel nested transaction executes a retry, a read set of the transaction is registered for the retry. When a decision is made to propagate the retry past a parallel nested transaction parent of the transaction, keeping the read set registered and making the read set part of a parent read set.

Parallel nested transactions in transactional memory

Software transactional memory (STM) primitives are provided that allow the results of prior open calls to be used by subsequent open calls either as-is or through another STM primitive that consumes the results of the previous invocation. The STM primitives are configured to ensure that the address of a shadow copy representing a memory location will not changed across a wide range of operations and thereby enable re-use of the shadow copy.

Primitives for software transactional memory

Loop control flow diversion supports thread synchronization, garbage collection, and other situations involving suspension of long-running loops. Divertible loops have a loop body, a loop top, an indirection cell containing a loop top address, and a loop jump instruction sequence which references the indirection cell. In normal execution, control flows through the indirection cell to the loop top. After the indirection cell is altered, however, execution flow is diverted to a point away from the loop top. Operations such as garbage collection are performed while the loop (and hence the thread(s) using the loop) is thus diverted. The kernel or another thread then restores the loop top address into the indirection cell, and execution flow again continues through the restored indirection cell to the loop top.

Loop control flow diversion

A compiler is provided that determines when the use of software transactional memory (STM) primitives may be optimized with respect to a set of collectively dominating STM primitives. The compiler analysis coordinates the use of variables containing possible shadow copy pointers to allow the analysis to be performed for both direct write and buffered write STM systems. The coordination of the variables containing the possible shadow copy pointers ensures that the results of STM primitives are properly reused. The compiler analysis identifies memory accesses where STM primitives may be eliminated, combined, or substituted for lower overhead STM primitives.

Optimizing primitives in software transactional memory

An error handling system is described herein that provides a facility for controlling the behavior of software when the software violates a contract condition. The system provides configurable runtime behavior that takes place when a contract fails. The error handling system provides an event that a hosting application or other software code can register to handle and that the system invokes upon detecting a contract failure. The application's response to the event determines how the system handles the failure. If the event is unhandled, the system triggers an escalation policy that allows an administrator or application to specify how the system handles contract failures. Thus, the error handling system provides increased control over the handling of contract failures within software code.

Contract failure behavior with escalation policy

A dynamic race detection system is provided that detects race conditions in code that executes concurrently in a computer system. The dynamic race detection system uses a modified software transactional memory (STM) system to detect race conditions. A compiler converts portions of the code that are not configured to operate with the STM system into pseudo STM code that operates with the STM system. The dynamic race detection system detects race conditions in response to either a pseudo STM transaction in the pseudo STM code failing to validate when executed or an actual STM transaction failing to validate when executed because of conflict with a concurrent pseudo STM transaction.

Detecting race conditions with a software transactional memory system

A software transactional memory (STM) system allows the composition of traditional lock based synchronization with transactions in STM code. The STM system acquires each traditional lock the first time that a corresponding traditional lock acquire is encountered inside a transaction and defers all traditional lock releases until a top level transaction in a transaction nest commits or aborts. The STM system maintains state information associated with traditional lock operations in transactions and uses the state information to eliminate deferred traditional lock operations that are redundant. The STM system integrates with systems that implement garbage collection.

Composition of locks in software transactional memory

A software transactional memory system is provided with overflow handling. The system includes a global version counter with an epoch number and a version number. The system accesses the global version counter prior to and subsequent to memory accesses of transactions to validate read accesses of the transaction. The system includes mechanisms to detect global version number overflow and may allow some or all transactions to execute to completion subsequent to the global version number overflowing. The system also provides publication, privatization, and granular safety properties.

STM with global version overflow handling

Various technologies and techniques are disclosed that provide software transactional protection of managed pointers. A software transactional memory system interacts with and/or includes a compiler. At compile time, the compiler determines that there are one or more reference arguments in one or more code segments being compiled whose source cannot be recovered. The compiler executes a procedure to select one or more appropriate techniques or combinations thereof for communicating the sources of the referenced variables to the called code segments to ensure the referenced variables can be recovered when needed. Some examples of these techniques include a fattened by-ref technique, a static fattening technique, a dynamic ByRefInfo type technique, and others. One or more combinations of these techniques can be used as appropriate.

Software transactional protection of managed pointers

Various technologies and techniques are disclosed for providing type stability techniques to enhance contention management. A reference counting mechanism is provided that enables transactions to safely examine states of other transactions. Contention management is facilitated using the reference counting mechanism. When a conflict is detected between two transactions, owning transaction information is obtained. A reference count of the owning transaction is incremented. The system ensures that the correct transaction was incremented. If the owning transaction is still a conflicting transaction, then a contention management decision is made to determine proper resolution. When the decision is made, the reference count on the owning transaction is decremented by the conflicting transaction. When each transaction completes, the reference counts it holds to itself is decremented. Data structures cannot be deallocated until their reference count is zero. Dedicated type-stable allocation pools can be reduced using an unstable attribute.

Using type stability to facilitate contention management

Handling garbage collection and exceptions in hardware assisted transactions. Embodiments are practiced in a computing environment including a hardware assisted transaction system. Embodiments includes acts for writing to a card table outside of a transaction; handling garbage collection compaction occurring when a hardware transaction is active by using a common global variable and instructing one or more agents to write to the common global variable any time an operation is performed which may change an object's virtual address; acts for managing a thread-local allocation context; acts for handling exceptions while in a hardware assisted transaction. A method includes beginning a hardware assisted transaction, raising an exception while in the hardware assisted transaction, including creating an exception object, determining that the transaction should be rolled back, and as a result of determining that the transaction should be rolled back, marshaling the exception object out of the hardware assisted transaction.

Growing community of inventors

Sammamish, WA, United States of America

Michael M Magruder