Using a hash table to store transaction records is an interesting compromise between object and field granularity because it allows the probability of false conflicts to be controlled without requiring lots of additional space to independently track each field. There is also opportunity to use multiple hash tables in ways that take advantage of the program's behavior.

But doesnt this hashtable increase the space requirement?

This slide talks about having a transaction record for each object vs for each element. This determines the granularity of conflict detection. With coarser level txn records, the overhead is lesser but there will be false conflicts which reduce room for concurrency. This is similar to the case in cache coherence.

Can this be determined per-data structure including new generated ones? Or is this a more general policy?

In STM, is the operating system completely oblivious to the fact that there is a hash table being used, and the process looks like a normal executable (that just happens to be using more memory to store reads/writes)?