#1 is a dup of #17133. I'm intending to fix this for 1.9.

#2 is more difficult. The hash depends on the state of the map, and outside the lock it is unreliable to look at the state of the map. In addition, whether to hash at all depends on the state of the map - for small maps we don't hash at all. That also depends on the state of the map that we can't reliably detect outside the lock. Doing the hash unconditionally would be a performance regression for small maps.

I'm going to close this for now, I don't think there is anything we can do for #2.

If the hash can change based on the state of the map, doesn't that mean this code can't optimize away either of the hash calculations? The newValue() function call might itself mutate the state of the map.

@quentinmit : To be more specific, the hash depends on the initial seed chosen for each map. So in the example given the hash will always be the same before and after newValue. (Whether we need to do the hash at all can change across the call to newValue. We could probably handle that complication, it would just lead to some wasted work.)

The hard part about computing the hash outside the lock is that we can't read that seed out of the map because such a read would be racy.

The hash depends on the state of the map, and outside the lock it is unreliable to look at the state of the map. In addition, whether to hash at all depends on the state of the map - for small maps we don't hash at all. That also depends on the state of the map that we can't reliably detect outside the lock. Doing the hash unconditionally would be a performance regression for small maps.

The compiler can do 'optimistic' hash calculation outside the lock - i.e. calculate the hash only if hash seed is already set and the map size is big enough to calculate the hash. Otherwise fall back to in-place hash calculation.

Additionally, it looks like the compiler shouldn't know anything about the lock - it should just insert the 'optimistic' hash calculation to the beginning of basic block where the map is accessed by key.

Just realized the 'optimistic' hash calculation won't work if the map may be substituted during program execution:

func cleanMap() {
    mu.Lock()
    // This breaks 'optimistic' hash calculations :(
    m = make(map[string]Value)
    mu.Unlock()
}

Probably the compiler may use optimistic hash calculation only if it could prove that the map variable is never re-assigned after the initial assignment.
Or insert additional checks before each map access whether the map variable re-assigned after the optimistic hash calculation.