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~
May 22, 2015
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