remove glib dependency

[1a1a11a]

Glib was used in the early stage of this project, but given that it is not used in new implementations, we consider removing this dependency. To do this, we first need to find out all the usages of glib and think about an alternative. For example, GHashtable is used in several places, but we can use a self-contained header-only hash table.

[mack-w]

Hi! Would like to head into this project by taking this issue. May I confirm whether this is being worked on?

[1a1a11a]

Go ahead.

[mack-w]

forked repo: mack-w/libCacheSim

I checked compiled binaries and found that the majority of references to gLib are hash table functions. There are also references to thread pooling, mutex, arrays and queues, etc. but seems that they are limited i.e. only a few references in the entire code base.

For now I looked into several single header hash table implementations and found that sheredom/hashmap.h seems to be a choice: compatible with C, no need to worry size of hashtable, as simple as putting it into include/. For thread pool I also found an excellent blog describing a simple C thread pool, but I may write one myself if I found that insufficient. For other less referred utilities, I can try to reimplement gLib behavior with system libs.

Do you think this arrangement is acceptable?

[1a1a11a]

Awesome! I like the proposal.
There was also the dataStructure folder, which contains some header-only libraries, but I do not have a strong opinion on which one you use, if you decide to go with the one you proposed, you can also clean up the data structure folder so that we will use the same one library consistently.

[mack-w]

Oh okay, didn't really noticed it beforehand... I checked existing implementations and it seems that we have a hash table, so I will go for that. For thread pool, seems that in traceAnalyzer there's a C++ thread pool, but it isn't currently used. I'm gonna either try to move it up to include/ or just use some pure C thread pool. For other gLib funcs I'll just rewrite them or use stuff in dataStructure/ut.

[1a1a11a]

Sounds good! It would be better not to involve C++, otherwise, it might require a lot of work to update other parts. The hash table in dataStructure is tightly coupled with cache_obj; it might be easier to use the generic ones, but I leave it to you.

[mack-w]

Fair enough, I'm gonna check the hash table more closely and make a choice. I'll leave a comment here if I need help or clarification.

Update: sheredom/hashmap.h seems good with a minor glitch, cachesim moved to hashmap.h. Will continue with that

Update: migrated Reader and MRC related stuff. Now comes cache admission/eviction algorithms, will choose between hashmap.h or hash table in dataStructure/ based on the code