merlimat commented on pull request #9764: URL: https://github.com/apache/pulsar/pull/9764#issuecomment-788203612
> There are tradeoffs involved. Some memory allocations will have to be made to make a copy. However, allocations aren't a real issue. JVMs are really efficient for such short time allocations and the allocations aren't causing new bottlenecks or performance issues. The primary goal of having these custom concurrent maps implementation was actually to avoid memory allocations to the max possible extent :) Even if these allocations are short lived, they still contribute to generate garbage that will fill up the new-gen space at a faster rate. That in turn will cause more "in-flight", reasonably short-lived objects to get caught in a collection event and copied over to old-gen spaces, where they'll have to get compacted later on. On the class there are also already 2 methods, `keys()` and `values()`, that are taking copies, thought they were put there mostly to simplify unit tests. > The I/O usually happens to Zookeeper and it leads to threads piling up in waiting for locks in ConcurrentOpenHashMap when there are both reads and writes for the same section in concurrently executing threads. We shouldn't be doing blocking calls from within the process method. I think we should rather refactor that code instead. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
