common/lru: add generic LRU implementation

[fjl]

It seems there is no fully typed library implementation of an LRU cache. So I wrote one.
Method names are the same as github.com/hashicorp/golang-lru and the new type can be used as a drop-in replacement (mostly).

Two reasons to do this:

• It's much easier to understand what a cache is for when the types are right there.
• Performance: the new implementation performs zero memory allocations in Add
  when the cache is at capacity. Results for BasicLRU[int, int] below.

goos: darwin
goarch: arm64
pkg: github.com/ethereum/go-ethereum/common/lru
BenchmarkLRU/Add/BasicLRU-8         	20671774	        58.07 ns/op	       0 B/op	       0 allocs/op
BenchmarkLRU/Add/simplelru.LRU-8    	 8095117	       146.8 ns/op	      96 B/op	       3 allocs/op
BenchmarkLRU/Get/BasicLRU-8         	56364932	        21.17 ns/op	       0 B/op	       0 allocs/op
BenchmarkLRU/Get/simplelru.LRU-8    	43399506	        27.83 ns/op	       0 B/op	       0 allocs/op

[holiman]

One thing that I feel should be checked, is the behaviour with nil values. Right now, we never store nil nor empty code in the codecache, but that might change.

So basically, how does the SizeConstrainedCache cache behave with regards to nil vs 0-length byte arrays. (And how do we want it to behave?)

I'm just writing this down here so it isn't forgotten

[holiman]

// TestBlobEmpties tests that empty/nil values are handled correctly.
func TestBlobEmpties(t *testing.T) {
	lru := NewBlobLRU[common.Hash, []byte](100)
	// This test abuses the lru a bit, using different keys for identical value(s).
	for i := 0; i < 10; i++ {
		lru.Add(common.Hash{byte(i)}, []byte{})
		lru.Add(common.Hash{byte(255 - i)}, nil)
	}
	// The size should not count, only the values count. So this could be a DoS
	// since it basically has no cap, and it is intentionally overloaded with
	// different-keyed 0-length values.
	if have, want := lru.size, uint64(0); have != want {
		t.Fatalf("size wrong, have %d want %d", have, want)
	}
	for i := 0; i < 10; i++ {
		if v, ok := lru.Get(common.Hash{byte(i)}); !ok {
			t.Fatalf("test %d: expected presence", i)
		} else if v == nil {
			t.Fatalf("test %d, v is nil", i)
		}
		if v, ok := lru.Get(common.Hash{byte(255 - i)}); !ok {
			t.Fatalf("test %d: expected presence", i)
		} else if v != nil {
			t.Fatalf("test %d, v is not nil", i)
		}
	}
}

We could use this test. It even passes :)

[fjl]

Added the test.

[holiman]

LGTM

[ryanschneider]

FWIW looks like golang-lru/v2 w/ generics support landing the same day this PR was merged (weird coincidence?). Just mentioning in case you wanted to switch to it to slightly lower the amount of code you maintain.

[fjl]

To be fair, I did not check for open PRs on golang-lru at the time. I was pretty happy to find an opportunity for writing some plain-simple generics code.

As for switching back, it's unlikely for several reasons: I found that embedding the linked-list implementation enables additional optimizations in BasicLRU that weren't possible before. I don't know if these are possible and/or wanted upstream. We could try, but... honestly it feels easier to just maintain our own version here. It's not a massive amount of code anyway. It's also very unlikely to have bugs.

We also need a package to house our own cache related code (only the size-limited LRU), and it's nice being able to have everything together.

The golang-lru API has some quirks that make it annoying to use: lru.New returns an error, which is stupid, and the 'unlocked' LRU is in a separate package.