-
Notifications
You must be signed in to change notification settings - Fork 60
Making data available
On the previous page, Blob consumer lifecycle, we looked at an example where we loaded blob data into a FastBlobStateEngine. However, this example made a call to a mysterious method “makeDataAvailableToApplication”, which was unspecified. Let’s take a look at some possible implementations of this method.
When we have a FastBlobStateEngine populated with a deserialized data state, we can access all of the instances for any given type with the following code:
It’s likely that your applications will want to access this data by some primary key. In this case, you might iterate over all of the values for the relevant types, then index them by their primary key in a Map:
If your data set is large, you may run into a problem here with the garbage collector. Creating many HashMaps that stick around until the next cycle will cause a lot of long-lived objects supporting HashMap data structure to be created.
Zeno ships with an open-addressed Map implementation which, when used properly, will allow you to pool and then re-use these objects. This will cause these objects to be promoted only once, so that they do not cause GCs of long duration on each cycle.
The class is called HeapFriendlyHashMap, and the usage pattern looks like this:
When you use this class, you must perform some maintenance before and after making data available:
When using HeapFriendlyHashMaps, you are managing your own memory, so be careful. Never release the resources of a HeapFriendlyHashMap before you are sure that the map will no longer be used after the call to HeapFriendlyMapArrayRecycler.get().clearNextCycleObjectArrays() is called. If you make this call after releasing the resources of a Map which is in use, it will remove the contents of the Map. Always make sure that HeapFriendlyMapArrayRecycler.get().swapCycleObjectArrays() is called before making data available. Neglecting to do this will cause a memory leak.
All of our examples thus far have assumed that all of our blob consumers require exactly the same amount of data. Depending on your use case, this may not be true. Continue on to the next page producing multiple images to learn how to produce multiple images from a single state engine.



