Java Card 3.0.2 - Garbage Collection

user11216344

I am using a NXP J3D081 80K I am compiling against 3.0.2. I am trying to simulate a simple file system. The Write routine is simply:

public class File {

   public File Next;

   public byte[] Name;

   public byte Attributes;

   public short Length;

   public short Ptr;

   public byte[] Data;

  

   public byte Write(byte[] InData,short Offset, short InLength) {

       if (Length == 0) {

            Data = new byte[InLength];

       }

       else {

           byte[] tmp;

           tmp = new byte[(short)(Length+InLength)];

           Util.arrayCopyNonAtomic(Data,(short)0, tmp, (short) 0, Length);

           Data=null;

           Data=tmp;

           tmp=null;

       }

       Util.arrayCopyNonAtomic(InData,Offset,Data,Length,InLength);

       Length += InLength;

       return(1);

   }

....

}

I am trying to append data, so I allocate a new buffer the full size of the file, copy the old data in and then copy in the new data. It was my understanding that this card has garbage collection so the old byte array should be collected at some point, but I am returning JCSystem.getAvailableMemory(JCSystem.MEMORY_TYPE_PERSISTENT); and it shows that the memory available goes down by the size of the existing data array, so it is not garbage collected. Even after a power down/up of the card, the memory is not reclaimed.

What am I missing?????

patrick.vh-Oracle

Since the Java Card heap is in persistent memory, GC takes some time and some platform implementations are using very specific trigger to launch gc (e.g. memory almost full, or operation know to create garbage like application uninstall) instead of regularly trying to launch it.

In an application, you can use JCSystem.requestObjectDeletion() to schedule the gc. For performance reasons, you understand that you should use it only when you know you created garbage. The gc will get launched before the next call to Applet.process().

In addition, in order to reduce pressure on GC (and on persistent memory), I would also recommend to manage independently the total file size (size allocated in persistent memory, which could be the data.length ) from actual data size in the file (length field). You could for example extend your file by bigger chunks (64b or 128b each) and just increase the length by the real number of data written.

Also, don't forget that the heap is persistent, so make sure that any field that do not need to survive across sessions (power-down/power-up) is in volatile memory (RAM). I'm referring here to your 'ptr' which looks like to be the current reading position in the file but does not seem to be something that need to be persistent. If you need to have fields in RAM, consider using a specific context object, internally using one of the JCSystem.makeTransient<...>Array() methods.

I hope this will help!

6118c29f-c598-478c-a30e-5a7e4c3d92fc

If requesting garbage collection doesn't work then completely remove card from field. Some implementations require a full power down and some reader implementations may not always remove the field even on a hard reset.