Java Card memory leak in for loop? -
i know java card vm's doesn't have have garbage collector, happens for loop:
for(short x=0;x<10;x++) {} does x variable utilized after for loop, or turns garbage?
just in case have transient byte array called index size of 2 (instead of i in for loop) , use array in for loops:
for(index[0]=0;index[0]<10;index[0]++) {} but little slower first version. if use normal variable index in for loop gets slow.
so, happens x variable in first for loop? safe use for loops that, or not?
the x variable not exist in byte code. there operations on location in java stack represents x (be java byte code or code after conversion java card converter). java stack virtual stack. stack implemented on cpu has registers , non-virtual stack. in general, if there enough registers available, variable x put in register until out of scope. register may of course reused. cpu stack lifo (last in first out) queue in transient memory (ram). stack continuously grows , shrinks during execution of byte code makes applet. registers, stack memory reused on , on again. local variables (those defined inside code blocks method arguments) treated way.
if put variable in transient array putting variable on ram based heap. java card ram heap never go out of scope. means if update value change needs written transient memory. of course slower localized update of cpu register, found experimentation. memory in transient memory never freed. said, can of course reuse memory other purposes, long have reference array. note references (the index in index[0]) may either in persistent memory (eeprom or flash) or transient memory.
it's unclear mean "normal variable". if has been created new or if field in object instance persists in heap in persistent memory (eeprom or flash). eeprom , flash have limited amount of write cycles , writing eeprom or flash much slower writing ram.
java card contains 2 kinds of transient memory: clear_on_reset , clear_on_deselect. difference between 2 clear_on_reset allows memory shared between applet instances while clear_on_deselect allows memory reused different applets.
java card classic doesn't contain garbage collector runs during applet execution, can request garbage collection during startup using jcsystem.requestobjectdeletion() clean memory not referenced anymore, both on heap in transient memory in persistent memory. cleaning memory means scanning memory, marking unreferenced blocks , compacting memory. similar defragmenting hard disk; can take uncomfortably long time.
rom filled during manufacturing phase. may contain operating system, java card api implementation, byte code (including constants) of pre-loaded applets etc. read in field, isn't of consequence question asked.
Comments
Post a Comment