Integrating RAM and Disk Based Verification within the Mur Verifier

1
Integrating RAM and Disk Based Verification
within the Mur? Verifier

• Giuseppe Della Penna
• Benedetto Intrigila
• Igor Melatti
• University of LAquila
• Enrico Tronci
• Marisa Venturini Zilli
• University of Rome La Sapienza

2
Summary

• We want to integrate two explicit verification
  algorithms, a memory-based and a disk-based one,
  to obtain an algorithm that can switch from
  memory storage to disk storage when the memory is
  full.
• We do not want to simply merge these two
  algorithms this would make both slower
  (especially the memory-based one!)
• We use the concept of serialization to keep the
  two algorithms separate and allow the migration
  of the verification process.

3
Motivation

• Explicit verification needs many resources to run
  effectively
• time can be always given to the verifier, whereas
  
• memory is a more critical resource, since it
  often has to be fixed a priori.

Time
Verification
4
Motivation

• To give the verifier virtually unlimited space,
  we may use disk storage, but this would slow down
  the verification.
• If available memory is not enough, verification
  will stop after some time and the work done up to
  that point will be lost.

Verification
5
Serialization

• In OOP theory, serialize an object means to
  permanently save its state, so that it can be
  reloaded later in another object instance
  (deserialized).
• Similarly, in our context, serialize a
  verification means to save the information
  collected by the verifier, so that it can be
  reloaded in another verifier to continue the
  verification.

Permanent Storage
Verifier 2
Verification State
Verification State
6
Advantages

• With serialization-enabled verifiers, we can
• Save a verification and resume it with new
  resources available and possibly with a new
  verification strategy.
• Save the verifier work before it is lost due to
  software errors (e.g., out of memory) or system
  failures (e.g., a system shutdown).
• Create verification snapshots at regular time
  intervals, to analyze them offline or distribute
  them to other verifiers.

7
Serialization Schemas

• Enabling serialization in pre-existent verifiers
  is not easy. We must find out
• What has to be saved we cannot waste space or
  lose critical information
• How it has to be saved we need to define a
  generic format that can be used by different
  verification algorithms.
• Different verifiers (or verification algorithms)
  should be able to adapt the serialized image to
  initialize all their internal verification
  structures.

8
Murphi Implementation

• We implemented serialization within the Murphi
  verifier to integrate our cache-based (CMurphi,
  CHARME01) and disk-based (DMurphi, FMCAD02)
  verification algorithms.

9
Murphi Implementation
Verification Image
File1
File2
File3
10
Experimentation

• We simulated the typical out-of-memory situation
  by running CMurphi with minimal resources
• Verification begins in CMurphi. When memory runs
  out, CMurphi serializes its state
• then, we add space by using disk storage within
  DMurphi to resume and complete the verification.

Available Memory
Verification 1
CMurphi
Verification 2
DMurphi
CMurphi
11
Experimentation

• Results show that if we run the verification
  through both algorithms, starting with the
  fastest (CMurphi) and using the slowest (DMurphi)
  only if the former fails
• The total verification time is about the same as
  if we were using only the algorithm that actually
  completes the verification.
• Indeed, if we use CMurphi and then DMurphi, the
  verification time is on average 101 of the time
  taken by DMurphi only.

12
Conclusions

• The basic idea behind serialization is simple,
  but current state-of-the-art verifiers do not
  implement it.
• Indeed, adding serialization to a verifier can be
  very complex.
• We implemented serialization within Murphi to
  join memory-based and disk-based verification
  preliminary results in terms of performances are
  very encouraging.