NovaX

14 ms·

91.
by NovaX 6y ago
I have not used Spring since 2009 (where I used it daily) and have been using Java full time throughout. In that time I have written a lot of code and worked with many excellent teams. I’ve not had any of your problems because we always cho
92.
by NovaX 6y ago
You probably need to run ANALYZE to rebuild the statistics, as that doesn't happen automatically after an upgrade.
93.
by NovaX 6y ago
Have you tried making it adaptive [1]? Using hill climbing with a decay rate has a nice impact to correct for LRU-biased workloads [2]. [1] https://dl.acm.org/doi/10.1145/3274808.3274816 [2] https://git
94.
by NovaX 6y ago
It is a method-scoped variable that is operated on under the reader's lock. Therefore the additional locking by StringBuffer is unnecessary and there is no negative impact by switching to StringBuilder.
95.
by NovaX 6y ago
The vast majority of STMs use lock-based transaction management. There are lock-free designs, but these tend to perform worse due to creating a lot of memory bus traffic. Unfortunately lock-free algorithms can easily perform worse than thei
96.
by NovaX 6y ago
It is a stretch to claim caching is fundamentally at odds with GC. It is more correct to say that LRU breaks the generational hypothesis, because it prioritizes new entries which take a long time to be evicted. However many workloads are fr
97.
by NovaX 7y ago
In 2005. https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
98.
by NovaX 7y ago
They also refused Apple's offer to relicense LLVM to the GPL, contribute it to GCC, and assign copyright to FSF.
99.
by NovaX 7y ago
It isn't a problem if you design an API by following the rules (PECS). Use wildcards for method parameters when this is the desired behavior. It is not hard to do things right. https://howtodoinjava.com/java/generi
100.
by NovaX 7y ago
I am not familiar with the Go code, but in the Java version (Caffeine) this is handled by a per-entry state machine. The entry is written to the Map first and the policy work buffered for replaying. If the replay occurs out-of-order (e.g. c
101.
by NovaX 7y ago
There is not a lot of research in this area and I briefly outlined my understanding of the current state when responding to a github issue: https://github.com/ben-manes/caffeine/issues/345#issuecommen...
102.
by NovaX 7y ago
It is very common and often referred to as jitter. A variation, called scaled ttl, was nicely discussed in this video. https://www.youtube.com/watch?v=kxMKnx__uso
103.
by NovaX 7y ago
I believe the author is referring to this post, https://web.archive.org/web/20181209143223/https://plus.goog... Guava was always made available as Google's Java core utilities. I think it was always
104.
by NovaX 8y ago
> The other issue would be "taming" the ARC Has anyone considered replacing ARC? It actually has fairly poor hit rates compared to other policies, with very modest improvements over LRU. I also wonder how much ghost entries con
105.
by NovaX 8y ago
Guava cache's successor, Caffeine [1], handles the asynchronous case. In your scenario, you could set a timeout on the future as the entry will be discarded if the future results in an error. [1] https://github.com/ben-
106.
by NovaX 8y ago
We had 4-6 month cyclical code yellows. It's not unlike the game where 20% projects could only be within the same team without significant blowback. Things are only reasonable when used as designed, which is not how all of Google opera
107.
by NovaX 8y ago
There are many ways at Google to stop people from moving teams. For me it was a code yellow. I am hazy, but it was either referred to as indentured servitude or more politely stated as such by our senior director who expected 3 year stints.
108.
by NovaX 8y ago
It's also quite useful in caches, though still novel to do so: http://highscalability.com/blog/2019/2/25/design-of-a-modern...
109.
by NovaX 8y ago
Zipf is a little idealistic. It is perfect for a quick analysis as the base case that a cache should excel at. Unfortunately LRU doesn't because it can be easily polluted. (examples: https://github.com/ben-manes/ca
110.
Design of a Modern Cache – Part Deux(highscalability.com)
6 points by NovaX 8y ago|0 comments
111.
by NovaX 8y ago
Yes, that would be fun. :) For fixed expiration (e.g. 5 min TTL), I use time-bounded LRU queues. Then if the head item has not expired, its successors have not either. If it has, it is merely a poll. For custom expiration (varies per-entry)
112.
by NovaX 8y ago
That certainly helps, though you assume strict LRU vs approximate ARC. One can of course use similar schemes on LRU (like memcached does) or sampling LRU, making it approximate but reducing the lock contention. The technique that I've
113.
by NovaX 8y ago
Naming aside, the structure is <LRU | LFU filter | LRU>. The latest version of that is adaptive, where the front LRU may grow or shrink based on the workload. This allows the cache to mimic LRU for recency-skewed workloads (e.g. job q
114.
by NovaX 8y ago
Can you explain how ARC can be more easily lock-free than LRU? ARC has to coordinate 4 doubly-linked lists and a pivot on every access.
115.
by NovaX 8y ago
The LHD paper lacks a robust analysis against different workloads. The few traces they use are either private or not considered representative workloads. For MSR, the provider (SNIA) specifically states: "WARNING: These traces are over
116.
by NovaX 8y ago
That makes sense, thanks! For microbenchmarks, I try to remove any overheads during runtime by precomputing. That means fully populating the map (only hits) and generating the distribution of keys. Then the threads start at a random index a
117.
by NovaX 8y ago
Thanks for the reply. I wasn't trying to critique your work, but when something seems wrong it's worth trying to understand why. That's either a mistake in the project or my understanding. Java and C++ concurrent maps scale r
118.
by NovaX 8y ago
The benchmark allocates a new ReadHandle on every get(key) operation, whose constructor performs work under a shared lock. This is a design flaw of the benchmark, not the library.
119.
by NovaX 8y ago
It is not lock-free. Every time he reads he acquires a lock by calling epochs.lock(). That may not explain the numbers entirely, but this benchmark is completely bogus.
120.
by NovaX 8y ago
His chart is very wrong: https://github.com/jonhoo/rust-evmap/blob/master/benchmark/r... Both Zipf (skewed) and Uniform distributions have the same read throughput. That would not occur because of h

More ›