TODO.txt

- discard whacky wraparound readings in python analysis script
- make the asyncenergymonitor discard whacky readings
    - this involves changing the storage? or keep it as strings, and then do the diffing on lastK or dump?
- make the output format of the asyncenergymonitor to be diffs instead of raw
    - this is better because then they dont need to manage wraparound, and they can
    - still rebuild the cumulative ones
- newest intel chips; find out your laptop's and see if there are newers
    - on server?
    - on laptop?
- regardless of if there is a new intel chip, see if there are mobile devices
  - made by intel with RAPL support -- thatd be the coolest in my opinion


- whats wrong with JMH JNI overhead
	- make sure this is still a problem and not something that you've figured out. i think this is fine now, and it's old concerns
	- compare JMH JNI overhead results to full runtime

- debug the size of the error bars on power per sample
- raw non-normalized results for sample period
- memory plots:
	- normalized
	- raw juxtaposed bars
	- percent difference
------------------------------------------------------------------------
<< Semi Immediates:
	- Get a complete lists of the benchmarks / more info about dacapo-evalution-git+309e1fa.jar
	- change 'time-between-samples' to 'time-per-sample' JSON field in the async-monitors result gathering

<< Other Todos:
	- jjoules compared with jRAPL
		- probably just keep jjoules's existence as a mental not for future challenges, but let sleeping dogs lie, yankow?
	- figure out why -O{1,2,3} flags mess things up. Almost positive it's bc it optimizes out the assembly code required to getSocketNum() (as per my gdb run)
		- does compiling with clang cause a segfault on non debian machine?
		- where does the clang segfault happen? it's somewhere in AsyncEnergyMonitorCSide. easy enough to fix?
		- what exactly is the problem with clang and debian?
	- cite the rapl-read.weebseeksjsndmfjee.edu stuff in your code or in the paper. (we know this is legit because he did power measurement validation though external, also verifiable means`)
		- where you got the MSR offsets from (and how you know they're correct)
		- the table with the CPU microarchitectures and their supported power domains
	- have Java check if kernel msr module is loaded, if not, exit and inform the user to `sudo modprobe msr`. can do it in the shell with `lsmod | awk '{print $1}' | grep '^msr\s*.*$'`
		- this can be generally handled as a way of graceful exception handling for unavailable resources. also could be good for 'this is not supported on your machine' although it breaking can already be enough to inform users that this isn't supported.