Speaker: Jungkuk Kim

Storing a Persistent Transactional Object Heap on Flash MemoryACM 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

TINYSTORE

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

TINYSTORE 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#0Sector#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

TINYSTORE 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 TINYSTORE’s API calls using references

references unique ID that TINYSTORE 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

TINYSTORE 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

TINYSTORE 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

tflash (ns) = 100 nr + 30 x 103 nw + 500 x 106 ne

teeprom (ns)= 100 nr + 30 x 103 nw + 3.5 x 106 ne

Nw, Nr, Ne : total counts, N :total # of fields modified , nw (amortized # of writes)= Nw / N

emulated Flash(NOR)

448KB, 8 KB erase unit

emulated EEPROM

TINYSTORE

JVMC 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

TINYSTORE

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