memory used by Locks

The lock manager is a such super-hot critical code path (probably the most hot critical code path) that it if it would have to wait on a memory allocation for each lock performance would tank. It probably allocates large memory blocks and manages them on it's own. I wouldn't be surprised if it also reserves memory so that it does not run out of memory in some critical code paths.

Addendum to @RemusRusanu's answer (wouldn't fit in a comment)...

Given that the database engine will permit up to 5000 locks per object before escalating and taking into account Remus’s answer regarding the critical nature of the lock manager, the high reservation starts to look plausible:

5000 (locks) * 10 (tables or indexes) * 96 (bytes per lock) * 1000 (concurrent queries) = 4.47GB

I would speculate the reservation is derived from a combination of the available RAM and the current workload but haven’t seen it documented or blogged about anywhere. Could also speculate that your 128GB memory would have been considered generous in 2008 and the 7GB reservation is indicative of expecting a heavy OLTP workload at that size.

sys.dm_tran_lock shows locked resources and requests for locks on resources, not individual rows, that locked. Each locked resource will hold many rows and, possibly, other objects, locked.

Returns information about currently active lock manager resources. Each row represents a currently active request to the lock manager for a lock that has been granted or is waiting to be granted.

The columns in the result set are divided into two main groups: resource and request. The resource group describes the resource on which the lock request is being made, and the request group describes the lock request.