java-performance | small examples to test and explain simple Java | Runtime Evironment library

To be fair, it's very complicated to give an answer when Holger already linked the main idea via his answer; still I will try to.

Extra pressure on GC - may be. Extra time for a GC cycle to execute - most probably not. Ignorable? I'd say totally. In the end what you care from a GC - that it takes little time to reclaim lots of space, preferably with super tiny stop-the-world events.

Let's talk about the potential overhead in the GC main two phases : mark and evacuation/realocation (Shenandoah/ZGC). First mark phase, where GC finds out what is garbage (by actually identifying what is alive).

If objects that were created by the Stream internals are not reachable, they will never be scanned (zero overhead here) and if they are reachable, scanning them will be extremely fast. The other side of the story is: when you create an Object and GC might touch it while it's running in the mark phase, the slow path of a LoadBarrier (in case of Shenandoah) will be active. This will add some tens of ns I assume to the total time of that particular phase of the GC as well as some space in the SATB queues. Aleksey Shipilev in one talk said that he tried to measure the overhead from executing a single barrier and could not, so he measured 3 and the time was in the region of tens of ns. I don't know the exact details of ZGC, but a LoadBarrier is there in place too.

The main point is that this mark phase is done in a concurrent fashion, while the application is running, so you application will still run perfectly fine. And even if some GC code will be triggered to do something specific work (Load Barrier), it will be extremely fast and completely transparent to you.

The second phase is "compactation", or making space for future allocations. What a GC does is move live objects from regions with the most garbage (Shenandoah for sure) to regions that are empty. But only live objects. So if a certain region has 100 objects and only 1 is alive, only 1 will be moved, then that entire region is going to be marked as free. So potentially if the Stream implementation generated only garbage (i.e.: not currently alive), it is "free lunch" for GC, it will not even know it existed.

The better picture here is that this phase is still done concurrently. To keep the "concurrency" active, you need to know how much was allocated from start to end of a GC cycle. This amount is the minimum "extra" space you need to have on top of the java process in order for a GC to be happy.

So overall, you are looking at a super tiny impact; if any at all.

The loop presented likely falls under the "non counted" category of loops, which are loops for which the iteration count can neither be determined at compile time nor at run time. Not only because of @Andreas argument about the array size but also because of the randomly conditional break (that used to be in your benchmark when I wrote this post).

State-of-the-art compilers do not aggressively optimize them, since unrolling non-counted loops often involves duplicating also a loop’s exit condition, which thus only improves run-time performance if subsequent compiler optimizations can optimize the unrolled code. See this 2017 paper for details where they make proposals how to unroll such stuff too.

From this follows, that your assumption does not hold that you did sort of "manual unrolling" of the loop. You're considering it a basic loop unrolling technique to transform an iteration over an array with conditional break to an && chained boolean expression. I'd consider this a rather special case and would be surprised to find a hot-spot optimizer do a complex refactoring on the fly. Here they're discussing what it actually might do, perhaps this reference is interesting.

This would reflect closer the mechanics of a contemporary unrolling and is perhaps still nowhere near what unrolled machine code would look like:

First your block if here : for (int i = 3; i <= Math.sqrt(n); i += 2) { if (n % i == 0) {...

should be out of the loop,

Secondly, you can perform this code with differents methodes like :

while (n % 2 == 0) { Current++; n /= 2; }

you can change it with : if(n % 2 ==0) { current++; n=n%2; }

Essentially, you should avoid conditions or instruction inside loops because of your methode:

(findNumberWithNPrimeFactors)

the complexity of your algorithm is the complexity of each loop (findNumberWithNPrimeFactors) X ( iteration number )

if you add a test or an affectation inside your loop you will get a + 1 ( Complexity (findNumberWithNPrimeFactors) X ( iteration number ) )

Not exactly, but Java 7 added the ForkJoinPool, which was specifically meant to execute decomposed subtasks (parts of a larger task) in parallel. This could easily be applied to a Collection.

Java 5 also added the ThreadPoolExecutor, which isn't specifically for running decomposed subtasks, but it could still be used for it with a little more work.

Well if your strings are unique enough (e.g., generated via a cryptographic hash¹) synchronizing on client IDs will probably work, as long as you call String.intern() on them first. Since the IDs are unique, you aren't likely to run into conflicts with other modules, unless you happen to pass your IDs in to them and they follow the bad practice of locking on them.

That said, it is probably a bad idea. In addition to the small chance of one day running into unnecessary contention if someone else locks on the same String instance, the main problem is that you have to intern() all your String objects, and this often suffers from poor performance because of the native implementation of the string intern table, it's fixed size, etc. If you really need to lock based only on a String, you are better off using Guava's Interners.newWeakInterner() interner implementation, which is likely to perform much better. Wrap your string in another class to avoid clashing on the built-in String lock. More details on that approach in this answer.

Besides that, there is often another natural object to lock on, such as a lock in a session object, etc.

This is quite similar to this question which has more fleshed out answers.

¹ ... or, at a minimum, have at least have enough bits to make collision unlikely enough and if your client IDs aren't part of your attack surface.

Failed to open /tmp/perf-9931.map message is not about incorrect debuginfo - it is about profiling code which was generated by JIT (and Java usually generate machine code from class files with JIT), when there was no compatible with perf profiling agent running.

In http://www.brendangregg.com/perf.html#JIT_Symbols there is recommendation "Java can do this with perf-map-agent" to use https://github.com/jvm-profiling-tools/perf-map-agent which will generate map files for perf:

Architecture

Linux perf tools will expect symbols for code executed from unknown memory regions at /tmp/perf-.map. This allows runtimes that generate code on the fly to supply dynamic symbol mappings to be used with the perf suite of tools.

perf-map-agent is an agent that will generate such a mapping file for Java applications. It consists of a Java agent written C and a small Java bootstrap application which attaches the agent to a running Java process.

When the agent is attached it instructs the JVM to report code blobs generated by the JVM at runtime for various purposes. Most importantly, this includes JIT-compiled methods but also various dynamically-generated infrastructure parts like the dynamically created interpreter, adaptors, and jump tables for virtual dispatch (see vtable and itable entries). The agent creates a /tmp/perf-.map file which it fills with one line per code blob that maps a memory location to a code blob name.

The Java application takes the PID of a Java process as an argument and an arbitrary number of additional arguments which it passes to the agent. It then attaches to the target process and instructs it to load the agent library.

And in https://www.slideshare.net/brendangregg/java-performance-analysis-on-linux-with-flame-graphs Gregg used special hacked build of OpenJDK - slide 36 - "-XX:+PreserveFramePointer •  I hacked OpenJDK x86_64 to support frame pointers".

And from slide 41 Gregg talks about /tmp/perf-*.map files:

Fixing Symbols

 • For JIT'd code, Linux perf already looks for an externally provided symbol file: /tmp/perf-PID.map, and warns if it doesn't exist •  This file can be created by a Java agent

-XX:-UseCodeCacheFlushing disables sweeping compiled methods altogether.

Though this is the answer to the given question, I highly doubt this will resolve your original problem.

When an application is idle, NMethod sweeper is also idle. It is also unlikely that JIT compilation is so slow that it takes tens of seconds before the hot code is (re-)compiled. Flushed file caches, stale network connections etc. are more likely reasons for such slowdowns.

As mentioned in the comment by Mike Nakis the difference between your tests with random parameters vs those with fixed parameters is entirely due to the expense of generating the random number, a fairer test might be to generate a 10 million entry array of random integers (1 for each parameter needed to initialise a Point) before engaging the loop and comparing that to a 10 million entry array of number picked by you (i.e 1 and 2) that way you are comparing like for like, without including the expense of the random number generation in your test results.

The reason why your pool is performing worse than initialising new objects each time(at least in terms of execution time), is because the object that you are storing in your pool is a relatively trivial object that will take next to no time to initialise. As such the conditional statement that you are evaluating:

How to reduce memory consumption?

1) Add -XX:+UseCompressedOops flag to your JVM startup.

2) Implement your own version of LinkedHashMap, optimized for your needs. I. e. use primitive int as a key instead of Integer, remove "previous" pointer if you don't need it, etc. Note that copying OpenJDK source might be impossible unless you wish to release your modified hash map implementation under GPLv2 license, because OpenJDK is GPLv2. However you can copy and modify LinkedHashMap implementation from Android Open Source Project, because it is Apache licensed.