Improve log statements for zombie references

[Sandared]

Is your feature request related to a problem? Please describe.

In the past we had some issues with zombie references in our data structure. Microstream did notice us with WARN level log statements like these:

2022-05-10T15:35:09,281 | WARN  | MicroStream-StorageChannel-3 | StorageEntityCache$Default | Storage GC marking encountered zombie ObjectId 1000000000000012019

However to find out what object type causes these zombie references we had to change the log level to DEBUG which causes a ton of log statements from microstream only to find the relevant log statements that give us a hint which object might cause these zombie references, e.g.,

2022-05-10T15:34:30,868 | DEBUG | pool-9-thread-1  | BinaryStorer$Default | Registering 1000000000000012019: java.time.LocalTime@1a60d342()
2022-05-10T15:34:30,870 | DEBUG | pool-9-thread-1  | BinaryStorer$Default | Storing     1000000000000012019: java.time.LocalTime@1a60d342()

In another case we had zombie references caused by Strings, which are used everywhere in our data model, therefore it was really hard to pinpoint the actual troublemaker.

Describe the solution you'd like

It would be awesome if the WARN level log statement could already provide us with the object type like the DEBUG level does. Even better would be the type hierarchy in which this occurs, e.g., my.object.Type -> my.object.Data -> my object.Zombie, as types like String usually can be used everywhere and not always a zombie reference is caused by a more telling type, like my.object.Zombie.

Describe alternatives you've considered

Well currently the only option I know of is to scan the DEBUG log statements and then making an educated guess which type might cause the zombie references

Additional context

---

[hg-ms]

Many thanks for the proposal. I agree that providing more information in the warning that helps to identify the related object(s) would useful.