You might use jProfiler or the netbeans profiler to analyze what kind of objects are not garbaged.
You can usually ignore the byte. char and String instances, they are usually the most used instances. Though based on the amount of space taken up by the byte instaces, it seem like some object somewhere is storing a lot of byte information (perhaps a StringStream ?). VirtualVM will show you which objects are referencing each byte instance, usally you need to look at only a few instances before a pattern developes.
Does the TreeStructureNode declare a byte, or an object that has a byte embedded? You should also look at the next 3 or 4 entries in the list.
The best way to track down a leak is to take multiple heap dumps and see what changed between them. VisualVM is very good for doing this because it can compare multiple memory snapshots (via the memory profiler) and show you what changed. You want to look for classes whose instances increase dramatically. Then it is a matter of doing a search through the source code, for example for occurances of "new TreeStructureNode", and then tracking down who created those objects and why they are not being released.