For static fields (Java enums, in particular), slot changes may be produced by the user id system as well as the system id system: The change for the system id system will be triggered by #storeStaticFieldValues() when the class metadata is bootstrapped, any explicit user space #store() that directly or indirectly persists a static field value will introduce a slot change in the user id system.

Both these changes will be go into the list processed by the FreespaceCommitter, thus the slot will be freed twice. In connection with freespace merging, this will lead to bogus freespace entries:

FREED: [A:4340,L:98]
FREED: [A:4438,L:102] // merged as [4340, 200]
FREED: [A:4438,L:102] // adds a bogus overlapping freespace slot, so there's [4340, 200] and [4438, 102]

Perhaps this could be fixed by adding "set" characteristics to the FreespaceCommitter's list, but this sounds like merely fixing the symptom. Ideally, system id system slot changes should take precedence over user id system entries - this could be achieved by having the user id system query its parent, but this sounds awkward and slow, plus it implicitly relies on the order of events (i.e. system slot changes must always precede user slot changes).