Storing a Persistent Transactional Object Heap on Flash Memory
Upcoming SlideShare
Loading in...5
×
 

Storing a Persistent Transactional Object Heap on Flash Memory

on

  • 379 views

 

Statistics

Views

Total Views
379
Views on SlideShare
379
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Interoperable: Applets developed with Java Card technology will run on any Java Card technology-enabled smart card, independently of the card vendor and underlying hardware. Secure: Java Card technology relies on the inherent security of the Java programming language to provide a secure execution environment. Designed through an open process, the platform's proven industry deployments and security evaluations ensure that card issuers benefit from the most capable and secure technology available today. Multi-Application-Capable: Java Card technology enables multiple applications to co-exist securely on a single smart card. Dynamic: New applications can be installed securely after a card has been issued, enabling card issuers to respond to their customer's changing needs dynamically. Compatible with Existing Standards: The Java Card API is compatible with international standards for smart cards such as ISO7816, or EMV. Major industry-specific standards such as Global Platform and ETSI refer to it. ------------------------------------------------------ The Java Card Virtual Machine Specification defines the features, services, and behavior that an implementation of the Java Card technology must support. It includes the instruction set of a Java Card Virtual Machine (VM), the supported subset of the Java language, and the file formats used to install applets and libraries into smart cards and other devices that host Java Card technology. The Java Card Runtime Environment Specification defines the necessary behavior of the runtime environment (RE) in any implementation of the Java Card technology, which must include implementations of the Java Card Virtual Machine, the Java Card API classes, and runtime support services such as the selection and deselection of applets. API for the Java Card Platform complements the Java Card Runtime Environment Specification, and describes the application programming interface of the Java Card technology. The API is compatible with formal international standards and industry-specific standards. It contains the class definitions required to support the Java Card VM and the Java Card RE.

Storing a Persistent Transactional Object Heap on Flash Memory Storing a Persistent Transactional Object Heap on Flash Memory Presentation Transcript

  • Speaker: Jungkuk Kim Storing a Persistent Transactional Object Heap on Flash Memory ACM 2006 Conference on Languages, Compilers, and Tools for Embedded Systems (LCTES ’06) ~o~
  • Java Card Platform
    • Java Card Technology
      • enables smart cards and other devices with very limited memory to run small applications (applets) that employ Java technology
      • provides smart card manufacturers with a secure and interoperable execution platform that can store and update multiple applications on a single device
      • compatible with existing smart card standards.
    • Almost any type of smart card can benefit from java card Technology
      • Subscriber Identity Module (SIM) cards , used in cell phones on most wireless networks
      • Financial cards supporting both online and offline transactions
      • Government and health-care identity cards
      • Cards that provide logical access and physical access to enterprise resources
      • Smart tickets for mass transit
    • EEPROM is widely used today to store Java Card objects
      • persistent random-access device
      • single byte to be read or written  data structures designed for RAM can be used
      • part of EEPROM is used for a commit buffer, which serves as redo or undo log
  • Contribution
    • T INY S TORE
      • to meet the requirement of Java Card implementations that use NOR flash as their persistent storage
      • heap sub-system that allows Java Cards to use flash memory efficiently
      • persistent, transactional, garbage-collected memory-management system
      • the first such system:
        • existing java cards use EEPROM which does not require sophisticated heap system
        • or emulate EEPROM on flash
  • Java Card Memory Model
    • In most java platforms (J2ME,J2SE,J2EE),
      • Objects : stored in volatile memory
      • Persistence : achieved by using files, databases
    • In Java Card Platform
      • Data structures manipulation
        • Java Card Objects : always persistent
        • Automatic values (the stack) : always transient
        • Arrays : persistent or transient
        • fields in new objects : automatically initialized to default value (zero)
      • three atomicity models for persistent data
        • accesses to data items : atomic and serialized (at least logically)
        • explicit transaction
          • to group together to a set of operations that are executed atomically
          • either completed successfully or rolled back to the prior state
          • can abort by explicit API, lack of resources, or system failure
          • doesn’t support nested or concurrent transactions
        • only used for a filling or copying a section of an array
          • atomically ( arraycopy ) / non-atomically ( arrayCopyNonAtomic )
          • optimization opportunity
      • Garbage collector included or not
  • Design Goals
    • Assumption
      • H/W characteristics of smart cards and java cards
        • a small RAM (1MB flash, 32KB/8KB ram) and slow clock speed
      • using Flash devices
        • memory mapped for reading  NOR (not for NAND)
        • special device driver routine for programming and erasing
    • T INY S TORE features and APIs
      • to be called by the JVM (java virtual machine) of the Java Card
      • API functions
        • to create persistent objects and arrays
        • allow JVM to explicitly delete objects and arrays if GC not used
        • access optimization : supports read-optimized and modify-optimized representation for objects
        • atomic explicit transaction support
        • automatic mark-sweep garbage collection
        • array utilities
      • wear-leveling
      • physical pointer is more efficient when read frequently
      • Implemented in C
  • Low-level Data Structures
    • same as TFFS (transactional flash file system for NOR) in prior study
    • Logical Pointers and structure of erase unit
    • Efficient Pruned Versioned Search Trees
      • to find objects, arrays, and other data items
      • one or two versions of search tree
      • (a dictionary data structure w/ ordered keys)
      • which formally is a directed acyclic graph w/ one or two roots
      • One version  read-only search tree for look-up operation
      • The other version  read-write version for new (key-value) pairs to be added, deleted, replaced
      • if the read-write version committed, it becomes read-only and older version disappears
      • O(log(n+k), where n : size of the read-only dictionary, k : # of modifications on read-write tree
    • Log Structure
      • log (journal) to perform certain operations atomically
      • array of fixed size of records called entries
      • fills entire erase unit and doesn’t have logical number
    HEADER logical erase unit Sector descriptor Sector#0 Sector#1 Sector descriptor Kind of data, # of erase, Error-detection Code, Etc. Objects, Arrays, Headers of objects & arrays, Search-tree nodes logical pointer (erase unit #, sector #)
  • Java Card Memory Management System
    • T INY S TORE supports
      • physical addressing of objects and arrays
      • object-optimized field modifications
      • array-optimized element modifications
      • global operations on array
      • garbage collection
    • JVM names objects and arrays in T INY S TORE ’s API calls using references
    • references  unique ID that T INY S TORE generates when objects created
    • In versioned search tree, called REF tree
      • to map references to the flash addresses of objects/arrays
      • Each leaf in the tree maps one reference
      • The leaf contains
        • the reference itself
        • kind
        • logical pointer
        • some additional data items
    Mapping References to Flash Address
    • Sometimes we compact the lists
      • if the lists doesn’t have room for a new value for the field and it reached maximal length
    •  we must compact it.
      • when the JVM requests its physical address by calling GetPhysicalPointer
    On-Flash Representation of Objects GUID Valid Flag Initialization Flag
  • On-Flash Representation of Arrays
    • Arrays larger than compile-time threshold t (we set 255 which is maximal number of field)
      • if the array is larger than one erase unit
      • if one or a few elements are modified more frequently than the rest
    • section descriptors are the leaves of the pruned versioned tree
      • search keys are the sequential section numbers
    • array utility functions for bulk operations by TinyStore rather than by JVM
    list of array records Valid Flag (‘0’ 이면 invalid) Initialization Flag (‘0’ 이면 filed 사용 )
  • Garbage Collection
    • T INY S TORE
      • provides support for GC in RAM-limited systems
      • supports a stop-the-world mark-sweep collector
      • GC regard the heap as a directed graph
        • vertices are objects and arrays
        • edges are object references
        • to deallocate all the objects and arrays that are not reachable from the roots
      • Stack of reference and mark flags are stored in GC unit (single erase unit)
      • two in-RAM indices into this array
        • Ram index b : points to the first element of the on-flash array
        • Ram index n : the first unused location in the on-flash array
    Stack of reference to know whether already been visited Mark flags indicates reachable or not (sorted order)
  • Transaction Supports and Atomicity
    • Commit buffer
      • conventional way to support atomicity and explicit transactions in Java Cards
      • two ways  values are duplicated in the buffer
        • undo log  the old values
        • redo log  the new values
      • appropriate for EEPROM implementations
    • T INY S TORE
      • both the old and new values are always stored persistently on flash w/o commit buffer
        •  because TinyStore always stores updated information in new memory location
      • to use a log (journal) data structure
        • doesn’t contain copies of fields/array elements
        • contain pointers to the new and/or old copies of objects and tree nodes
  • Experimental Setup
    • Configurations
    • 5 types of workloads ( object field modification operation type )
      • TotallyRandom : updates random fields within a random objects
      • 20/80AllFields : 20% hot objects (P=0.9) / 80% cold objects (P=0.1)
      • until 100,000 times erased for one erase unit
    • Metric
      • number of counts : read, write, erase operations
      • t flash (ns) = 100 n r + 30 x 10 3 n w + 500 x 10 6 n e
      • t eeprom (ns)= 100 n r + 30 x 10 3 n w + 3.5 x 10 6 n e
      • N w , N r , N e : total counts , N : total # of fields modified , n w (amortized # of writes) = N w / N
    emulated Flash (NOR) 448KB, 8 KB erase unit emulated EEPROM T INY S TORE JVM C program emulate Running applets GC disabled At most 2 record in lists 8KB erase unit
  • Experimental Results
    • < EEPROM operations >
    • Independent of fullness and object size
    • In-place update strategy
    • Inefficiency in copying of every fields to the commit buffer
    •  when large objects and all fields modified
    • < TinyStore operations >
    • highly dependent of fullness and workload
    • More write operations than EEPROM
    • In case of larger object, all fields
    • Fewer write (simply writes new field values ) than EEPROM
    • Fewer erasures
    •  Estimated times are much faster than EEPROM
  • Experimental Results
    • < Endurance >
    • TotallyRandom
    •  TinyStore incurs erasures due to REF tree
    • 20/80AllFields
    •  Better than EEPROM
  • Experimental Results
    • < Storage Overhead of TinyStore >
    • -> to create fixed-size arrays until we run out of memory, and then check allocated user data space
    • Overhead
    •  By REF tree , object descriptor, flags, NEXT field
    • Small arrays
    •  <=40% (flash), <=65% (eeprom)
    • Large arrays
    •  60~80% (flash), 83~98% (eeprom)
  • Experimental Results
    • < cost of explicit transaction >
    • Atomicity causes significant overhead
    • in EEPROM
    •  Caused by the need to write old values to log
    •  TinyStore slightly better
  • Conclusion
    • T INY S TORE
      • novel approach for storing a Java heap on NOR flash memory
      • the first attempt to implement a memory manager for Java Cards for flash
      • GC in systems that have very little RAM
      • NOR flash is used for marking objects and for storing the mark-stack
      • improved performance (estimated times) and endurance
      • by efficient atomicity and transaction mechanism
      • higher storage overhead
      • performance strongly influenced by
      • large flash erase units, small RAM size, and the need to manage small data
      • objects