Byteman is very good if you want to check specific acesses but using it to obtain comprehensive coverage information will be a very laborious task unless you can find some way of automatically generating access detection rules form the original method source or bytecode (by which time you are well on the way to implementing your own coverage tool :-( ) Byteman cannot be used to detect the structure of bytecode. It's rules merely follow your instructions about where to insert actions into bytecode. So they expect you to already know the locations at which it makes sense to insert your rules.
As for the negative space in your results set -- well,if you knew you had inserted rles at all places where a fieldc ould be read or written then you could subtract the set of fields indicated as read or written by a triggered rule from the full set and that woudl tell you what fields ahd not been written. Sosolving thefirst problem of identifying and generating rules answers this second one. Path coverage tools do essentially the same thing i.e.idenitfy each path element (called a basic block) through each method's bytecode and then allocate a flag arry for each element. The start of the basic blocks is modified to set the associated flag. At the end of the run any flags unset indicate blocks of code not visited.So,in theory the same canbe done for field (and also local variable accesses).
For bytecode path coverage I recommend you try suing a dedicated coverage tool like JaCoCo. However, I don't think this tool will tell you directly where field acesses and/or updates are performed (it tells you indirectly because the path coverage also implies data accesses but you have to infer this by eyeballing the code). I don't know of any other FOSS tools that do record this information. However, it ought to be fairly easy to modify JaCoCo or any other path coverage tool so that it also provides data access coverage results. I think you should post a requuest for this functionality on their site.