Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Use arity hashCode instead of proc#hash in CallableSelector #4494
Using proc#hash as the cache key means that you're only
Also note that this was causing a memory leak: each time we get a cache miss it creates a new cache entry, and the cache is unbounded.
Tried to add a test for this, but it doesn't seem like CallableSelectorTest runs / works.
Using proc#hash as the cache key means that you're only guaranteed to get a cache hit if exactly the same proc is being passed. Using arity.hashCode instead should satisfy the original reason for hashing the proc (disambiguate signatures based on the arity of the proc) while preventing cache misses. Also note that this was causing a memory leak: executing the code that relies on this caching would create a new cache entry on every invocation, slowly growing the size of the cache.
thanks @snowp ... vaguely recall this logic.
I can look into adding a test to verify that the correct Java method gets called, but not sure how to test the cache growth? Here's some code I used to demonstrate the leak: