xz
async-profiler
xz | async-profiler | |
---|---|---|
24 | 10 | |
160 | 7,152 | |
- | 1.6% | |
9.7 | 8.7 | |
about 2 months ago | 8 days ago | |
C | C++ | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
xz
-
XZ backdoor story – Initial analysis
Very funny. This one:
https://github.com/tukaani-project/xz/commits?author=thesame...
- Xz: Update maintainer and author info. The other maintainer suddenly disappeared
- Thanks Andres Freud
- The xz-utils backdoor has been removed
-
The xz sshd backdoor rabbithole goes quite a bit deeper
> The payload of the 'hack' contains fairly easy ways for the xz hackers to update the payload. They actually used it to remove a real issue where their hackery causes issues with valgrind that might lead to discovering it, and they also used it to release 5.6.1 which rewrites significant chunks;
The valgrind fix in 5.6.1 overwrites the same test files used in 5.6.0 instead of using the injection code's extension hooks. This is done with what should have been a highly suspicious commit: https://github.com/tukaani-project/xz/commit/6e636819e8f0703... - this replaces "random" test files with other "random" test files. The state reson is questionable to begin but not including the seed used when the the purpoted reason was to be able to re-create the files in the future is highly suspicous. This should have raised red flags bug no one was watching. I'd say this is another part of the operation that was much more sloppy than it needed to be.
-
Timeline of the xz open source attack
In https://archive.softwareheritage.org/browse/revision/e446ab7...
-
GitHub Disabled the Xz Repo
You're right, but maybe because there's nothing to see : https://github.com/tukaani-project/xz
- Xz Repository Censored by GitHub
- Backdoor in upstream xz/liblzma leading to SSH server compromise
- The Return of the Frame Pointers
async-profiler
-
JVM Profiling in Action
We'll use async-profiler and flame graphs for profiling. To simplify the process, we'll run the code using JBang.
-
The Return of the Frame Pointers
JIT'ed code is sadly poorly supported, but LLVM has had great hooks for noting each method that is produced and its address. So you can build a simple mixed-mode unwinder, pretty easily, but mostly in process.
I think Intel's DNN things dump their info out to some common file that perf can read instead, but because the *kernels* themselves reuse rbp throughout oneDNN, it's totally useless.
Finally, can any JVM folks explain this claim about DWARF info from the article:
> Doesn't exist for JIT'd runtimes like the Java JVM
that just sounds surprising to me. Is it off by default or literally not available? (Google searches have mostly pointed to people wanting to include the JNI/C side of a JVM stack, like https://github.com/async-profiler/async-profiler/issues/215).
- FLaNK Stack 29 Jan 2024
-
Tracking Java Native Memory with JDK Flight Recorder
debugging native calls in itself is also painful. I have switched to using async-profiler (https://github.com/async-profiler/async-profiler) instead of JFR for most of my usecases.
A. it tracks native calls by default
-
Show HN: Javaflame – Simple Flamegraph for your Java application
https://github.com/async-profiler/async-profiler#flame-graph...
Ok, Windows is not supported. But IntelliJ made a fork which works on Windows.
-
Lettuce (Redis) + Mybatis (MySQL) take up most of the CPU in production - Is it normal? Did you observe that in your environment? Any ways to optimize it?
Hi, today I used async-profiler to check the CPU usage of my Spring Boot app (just a normal backend) in production. Surprisingly, Lettuce (Redis) + Mybatis (MySQL) take up most of the CPU time. I am not talking about wall time here, but CPU time, since I know database requests need to wait for milliseconds and thus wall time will be very long. Therefore, I wonder:
-
A question about Http4s new major version
You can use async-profiler to see what is happening under the hood.
- Reducing code size in (Rust) librsvg by removing an unnecessary generic struct
-
what is your favorite programming trick/tool that not many People know about?
I have used visual vm quite a bit. https://github.com/async-profiler/async-profiler is also amazing... Throw the binary on the system and fire it up. It also profiles down into native code as well if you do that kind of thing.
What are some alternatives?
wasmtime - A fast and secure runtime for WebAssembly
jmh - https://openjdk.org/projects/code-tools/jmh
libarchive - Multi-format archive and compression library
container-jfr - Secure JDK Flight Recorder management for containerized JVMs
stencil-golang - Template repository for Golang applications
jfr-libraries - a list of libraries that generate JFR events
tukaani-project
Arthas - Alibaba Java Diagnostic Tool Arthas/Alibaba Java诊断利器Arthas
Folly - An open-source C++ library developed and used at Facebook.
opentelemetry-java-instrumentation - OpenTelemetry auto-instrumentation and instrumentation libraries for Java
freedesktop-sdk
junit-jfr - a JUnit 5 extension that generates JFR events