Static maps are inefficient and possibly not thread safe

[dbwiddis]

I realized after committing #1101 that the static memoized map I used in MacNetworks, while thread safe, would never be GC'd and thus should not have been static.

FreeBSDDisks has a non-thread-safe mountMap and diskMap.

These should be made thread-safe and instance-based maps, and the codebase should be analyzed for any other static maps or other data caches.

[dbwiddis]

OK, this is actually a bigger design question. What's happening is the result of a design decision when first creating the Networks classes. The way the Networks class is implemented is:

1. Platform-specific HAL instantiates a new platform-Networks object and calls its getNetworks method.
2. An abstract class calls core Java methods to get an enumeration of NetworkInterface objects.
3. The abstract class iterates over these objects to create a NetworkIF object (losing the platform-specific nature)
4. The updateNetworkStats method is called on each object, internally determining which OS's static update method to use
5. The static method has only the NetworkIF as an argument so it has no ability to use cached information from a single command that collects data from all the other objects. This forces a choice of running the same method repeatedly for individual interfaces, or saving the state in a static object (as currently implemented). Unfortunately as a static member of the class, it never goes away.

Similar requirements also occur in the collection of HWDiskStore objects and OSProcess objects, but each of these is handled differently. In the case of the disks, the platform-specific Disks classes handle everything internally to the platform specific application, which can be more efficient (e.g., call iostat with the disk specified for single calls, or without it to collect information for all the disks) but duplicates code. For the processes, the platform-specific OperatingSystem classes used to create the processes are passed as objects to the OSProcess object so their non-static methods can be accessed and state preserved, but the objects can be GC'd once the user is done with all the processes.

I'm not sure which of these three approaches is the best, and would appreciate some input from others. I'm also thinking of completely (and consistently) redesigning all of these classes to move in the direction of external data/driver classes, possibly as part of a major version bump.

Thoughts from other collabborators? Examples of someone you think has done it right?

[dbwiddis]

OK, did a refactoring of MacDisks that minimizes the duplication and keeps the efficiency. I'll close this issue with that PR but consider a full redesign of Disks/Networks/Processes with the next major version bump.