Unintended or unmediated data sharing is a frequent cause of insidious bugs in multithreaded programs. We present a tool called SharC (short for Sharing Checker) that allows a user to write lightweight annotations to declare how they believe objects are being shared between threads in their program. SharC uses a combination of static and dynamic analyses to check that the program conforms to this specification.

MashMaker is a web-based tool that makes it easy for a normal user to create web mashups by browsing around, without needing to type, or plan in advance what they want to do.

We present HeapSafe, a tool that uses reference counting to dynamically verify the soundness of manual memory management of C programs. HeapSafe relies on asimple extension to the usual malloc/free memory management API: delayed free scopes during which otherwise dangling references can exist. Porting programs for use with HeapSafe typically requires little effort (on average 0.6% oflines change), adds an average 11% time overhead (84% in the worst case), and increases space usage by an average of 13%. These results are based on portingover half a million lines of C code, including perl where we found sixpreviously unknown bugs.Many existing C programs continue to use unchecked manual memorymanagement. One reason is that programmers fear that moving to garbage collection is too big a risk. We believe that HeapSafe is a practical way toprovide safe memory management for such programs. Since HeapSafe checks existing memory management rather than changing it, programmers need not worrythat HeapSafe will introduce new bugs; and, since HeapSafe does not managememory itself, programmers can choose to deploy their programs without HeapSafe if performance is critical (a simple header file allows HeapSafe programs to compile and run with a regular C compiler). In contrast, we foundthat garbage collection, although faster, had much higher space overhead, and occasionally caused a space-usage explosion that made the program unusable.

Article Share on MashMaker: mashups for the masses Authors: Robert J. Ennals Intel Research Berkeley, Berkeley, CA Intel Research Berkeley, Berkeley, CAView Profile , Minos N. Garofalakis Yahoo! Research, Santa Clara, CA Yahoo! Research, Santa Clara, CAView Profile Authors Info & Claims SIGMOD '07: Proceedings of the 2007 ACM SIGMOD international conference on Management of dataJune 2007 Pages 1116–1118https://doi.org/10.1145/1247480.1247626Online:11 June 2007Publication History 109citation39DownloadsMetricsTotal Citations109Total Downloads39Last 12 Months11Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Article Share on HsDebug: debugging lazy programs by not being lazy Authors: Robert Ennals University of Cambridge University of CambridgeView Profile , Simon Peyton Jones Microsoft Research Ltd, Cambridge Microsoft Research Ltd, CambridgeView Profile Authors Info & Claims Haskell '03: Proceedings of the 2003 ACM SIGPLAN workshop on HaskellAugust 2003Pages 84–87https://doi.org/10.1145/871895.871904Published:28 August 2003Publication History 7citation345DownloadsMetricsTotal Citations7Total Downloads345Last 12 Months7Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this observation. Optimistic Evaluation complements compile-time analyses with run-time experiments: it evaluates a thunk speculatively, but has an abortion mechanism to back out if it makes a bad choice. A run-time adaption mechanism records expressions found to be unsuitable for speculative evaluation, and arranges for them to be evaluated more lazily in the future.We have implemented optimistic evaluation in the Glasgow Haskell Compiler. The results are encouraging: many programs speed up significantly (5-25%), some improve dramatically, and none go more than 15% slower.

No abstract available.

No abstract available.