Download - CLR Reliability under Memory Exhaustion

07/09/04 Windows Reliability Team 1

CLR Reliability under Memory Exhaustion

Solomon Boulos


Temporary Memory Exhaustion causes failures

• Out of Memory (OOM) is temporary• Shouldn’t cause failure

– Just wait for memory to become available– System take action to free up memory

• All managed code depends on CLR• Testing is difficult

– Exceptions are objects– Boxing (casting value type to object)– JIT compilation


Overview

• Previous Work– Reliability Working Group– Improvements for Whidbey

• OOM behavior– Everett (CLR v1.1)– Whidbey (CLR v2.0)– WinFX

• Solutions– Transactions– Recovery


Reliability Working Group

• Discussion of CLR reliability issues

• Interaction with Yukon and Avalon teams

• FailFast Behavior

• Controversial Decisions

• Fault Injection


Improvements for Whidbey

• CLR hardened to Out of Memory (OOM)

• Constrained Execution Regions (CERs)– Eagerly Prepared (No JIT Compiling)– Blocks ThreadAbort

• Reliability Contracts– Describes reliability attributes of code– Allows for function calls within CER

• Unhandled Exception Policy


My Approach

• Exhaust Memory (Not fault injection)

• Find failure points

• Consistently reproduce results

• Examine underlying causes

• Develop solutions


Everett OOM Behavior

• Different classes of failures– Catchable Out of Memory (OOM) Exception– Type Initialization Exception– Invalid Program exception from JIT compiler– Fatal OOM Error– Fatal Execution Engine error


Supporting Datavoid ManagedFunction(){

Regex* myReg = new Regex("*");

}Available Memory Observed Behavior

0-5860K Fatal Error

5892-5912K InvalidProgram

5924-5960K TypeInit

5890-Above Success


Fault Injection Examplestatic void Main(string[] args){try

{ // operations in here

}catch ( OutOfMemoryException ){Console.WriteLine(“Nothing should get past me.");}

}


Whidbey OOM Behavior

• See OOM Exception instead of– TypeInit– InvalidProgram

• Exception to Native host is COMPlusException– Not very helpful

• Fatal OOM only during initialization– Initialization can be large though (e.g. 10MB)

• CERs provide defense, but dangerous– CER { for (;;) } cannot be stopped

• Reliability Contracts = Honor System


• Swallows exceptions

• Shell– Crashes and restarts

• WinFS– Silent Process Failure

• Indigo– False Completion

WinFX Case Studies

Base OSBase OS

Whidbey

WinFX


Shell Failure

• Exhaust System Memory

• CLR throws OOM Exception

• Shell doesn’t catch

• Escalates to unhandled Win32 exception

• Shell crashes and restarts– Major disruption to user


WinFS Test

• Simple Contact Store Functions– AddContact– RenameContact– RemoveContact– ListContacts– ReachMemory


WinFS Test Normal Execution

• ListContacts() : “No Contacts Found”• AddContact(“Shane”) : Shane is added• ListContacts(): “Shane”• RenameContact(“Shane”, “Bob”): Shane is now

Bob• ListContacts(): “Bob”• RemoveContact(“Bob”): Bob is now deleted• ListContacts(): “No Contacts Found”


WinFS Test Stressed Execution

• ListContacts() : “No Contacts Found”

• ReachMemory(8MB): 8MB Available

• AddContact(“Shane”) : Shane should be added

• ListContacts(): “No Contacts Found”

• Process Exits


Indigo Test Specifications

• Client::SendMessage(): – Sends message to server and prints confirmation of

sending.

• Client::ReceiveMessage(): – Prints received message.

• Server::SendMessage(): – Sends message to client and prints confirmation of

sending.

• Server::ReceiveMessage(): – Prints message and responds with SendMessage()


Indigo Test Behavior

• Normal Execution– Client::SendMessage()– Server::ReceiveMessage()– Server::SendMessage()– Client::ReceiveMessage()

• Execution with Memory Pressure– Client::SendMessage()– Server::ReceiveMessage()– Server::ExhaustMemory()– Server::SendMessage()– Client never receives message


Solutions

• Transactions– In Memory– Durable (backed by disk)

• Recovery– Creates Recovery Log– Allows state restore


Transaction Participantpublic TransactionParticipant(String _originalValue)

{ originalValue = _originalValue;

result = originalValue;}

public void Prepare(IPreparingEnlistment pe){ // do work for transactionresult = "New Value";// all is well, vote preparedpe.Prepared();

}


Transaction Participant Continuedpublic void Commit(IEnlistment e){

// no work to do, vote done e.EnlistmentDone();}public void Rollback(IEnlistment e){

// restore originalValue result = originalValue; if ( null != e ) e.EnlistmentDone();}


Simple Transaction ExampleTransactionParticipant tp = new TransactionParticipant(txtInput.Text);

try

{

using (TransactionScope s = new TransactionScope()){

Transaction.Current.VolatileEnlist(tp,false);

s.Consistent = true;

}

}

catch (TransactionAbortedException){}

txtInput.Text = tp.Result;


rNotepad Techniques

• Log user work– KeyPressed Records– Resize Records

• Write work to log file every second

• Write checkpoint every 30 seconds

• Upon startup, recover– Checkpoint speeds up recovery


Conclusion

• Testing is difficult but possible

• Temporary memory pressure shouldn’t cause failures

• Transactions and Recovery can provide resilient and recoverable solutions


Questions?

• More info athttp://windows/sites/reliavuls/CLR/default.aspx

Download - CLR Reliability under Memory Exhaustion

Top Related