<?xml version="1.0" encoding="UTF-8"?>
 <rdf:RDF xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://pinboard.in">
    <title>Pinboard (jm)</title>
    <link>https://pinboard.in/u:jm/public/</link>
    <description>recent bookmarks from jm</description>
    <items>
      <rdf:Seq>	<rdf:li rdf:resource="https://blog.nns.ee/2026/01/06/aike-ble/"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/2308.16862"/>
	<rdf:li rdf:resource="https://github.com/Netflix/hollow"/>
	<rdf:li rdf:resource="https://blog.jetbrains.com/blog/2024/04/04/full-line-code-completion-in-jetbrains-ides-all-you-need-to-know/#under-the-hood"/>
	<rdf:li rdf:resource="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/"/>
	<rdf:li rdf:resource="https://github.com/simdjson/simdjson-java"/>
	<rdf:li rdf:resource="https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2"/>
	<rdf:li rdf:resource="https://krzysztofslusarski.github.io/2022/12/12/async-manual.html"/>
	<rdf:li rdf:resource="https://twitter.com/nitsanw/status/1566677642748874753"/>
	<rdf:li rdf:resource="https://github.com/ulid/spec"/>
	<rdf:li rdf:resource="https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/"/>
	<rdf:li rdf:resource="https://github.com/resilience4j/resilience4j"/>
	<rdf:li rdf:resource="https://github.com/netty/netty/pull/10737/files"/>
	<rdf:li rdf:resource="https://blog.vanillajava.blog/2022/01/distributed-unique-time-stamp.html"/>
	<rdf:li rdf:resource="https://pkolaczk.github.io/overhead-of-optional/"/>
	<rdf:li rdf:resource="https://www.morling.dev/blog/fizzbuzz-simd-style/"/>
	<rdf:li rdf:resource="https://github.com/Granulate/gprofiler"/>
	<rdf:li rdf:resource="https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005577.html"/>
	<rdf:li rdf:resource="https://www.testcontainers.org/"/>
	<rdf:li rdf:resource="https://gceasy.io/"/>
	<rdf:li rdf:resource="https://aws.amazon.com/about-aws/whats-new/2020/09/aws-crt-http-client-in-aws-sdk-for-java-2x/"/>
	<rdf:li rdf:resource="https://github.com/apple/servicetalk/"/>
	<rdf:li rdf:resource="https://www.alluxio.io/blog/moving-from-apache-thrift-to-grpc-a-perspective-from-alluxio/"/>
	<rdf:li rdf:resource="https://news.ycombinator.com/item?id=8099840"/>
	<rdf:li rdf:resource="https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/"/>
	<rdf:li rdf:resource="https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo"/>
	<rdf:li rdf:resource="https://arxiv.org/abs/1902.04023"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/java-bytebuffer-leak.html"/>
	<rdf:li rdf:resource="https://blog.jetbrains.com/upsource/2016/08/03/what-to-look-for-in-java-8-code/"/>
	<rdf:li rdf:resource="https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-11-trap.html"/>
	<rdf:li rdf:resource="https://security.googleblog.com/2018/08/introducing-tink-cryptographic-software.html"/>
	<rdf:li rdf:resource="https://github.com/spotify/dockerfile-maven"/>
	<rdf:li rdf:resource="https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html"/>
	<rdf:li rdf:resource="https://github.com/airlift/jvmkill/blob/master/README.md"/>
	<rdf:li rdf:resource="https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html"/>
	<rdf:li rdf:resource="https://github.com/lemire/JavaFastPFOR"/>
	<rdf:li rdf:resource="https://lemire.me/blog/2018/03/13/iterating-over-hash-sets-quickly-in-java/"/>
	<rdf:li rdf:resource="https://github.com/airlift/aircompressor"/>
	<rdf:li rdf:resource="https://github.com/pmem/pcj/blob/master/README.md"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ"/>
	<rdf:li rdf:resource="https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html"/>
	<rdf:li rdf:resource="http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html"/>
	<rdf:li rdf:resource="https://github.com/AdoptOpenJDK/jitwatch"/>
	<rdf:li rdf:resource="https://plasma-umass.github.io/doppio-demo/"/>
	<rdf:li rdf:resource="https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76?__s=gf36pf8g1gjugcqh6ppo"/>
	<rdf:li rdf:resource="https://codahale.com/usl4j-and-you/"/>
	<rdf:li rdf:resource="https://shipilev.net/jvm-anatomy-park/10-string-intern/"/>
	<rdf:li rdf:resource="http://ercoppa.github.io/HadoopInternals/"/>
	<rdf:li rdf:resource="http://www.evanjones.ca/java-native-leak-bug.html"/>
	<rdf:li rdf:resource="https://github.com/tdunning/t-digest"/>
	<rdf:li rdf:resource="http://www.slideshare.net/dbryant_uk/j1-2015-debugging-java-apps-in-containers-no-heavy-welding-gear-required"/>
	<rdf:li rdf:resource="https://www.loggly.com/blog/lessons-learned-from-using-regexes-at-scale/"/>
	<rdf:li rdf:resource="https://groups.google.com/forum/#!topic/mechanical-sympathy/Ko8osOYLq4I"/>
	<rdf:li rdf:resource="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/"/>
	<rdf:li rdf:resource="https://github.com/ztellman/dirigiste"/>
	<rdf:li rdf:resource="https://koloboke.com/"/>
	<rdf:li rdf:resource="http://motherboard.vice.com/read/why-the-very-silly-oracle-v-google-trial-actually-matters"/>
	<rdf:li rdf:resource="https://github.com/uber-common/infer-plugin"/>
	<rdf:li rdf:resource="http://motherboard.vice.com/read/in-google-v-oracle-the-nerds-are-getting-owned"/>
	<rdf:li rdf:resource="https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/"/>
	<rdf:li rdf:resource="https://jitpack.io/"/>
	<rdf:li rdf:resource="https://github.com/ifesdjeen/hashed-wheel-timer"/>
	<rdf:li rdf:resource="https://github.com/JCTools/JCTools/pull/93"/>
	<rdf:li rdf:resource="https://github.com/conversant/disruptor"/>
	<rdf:li rdf:resource="https://www.lolware.net/2016/02/12/argon2-code-review.html"/>
	<rdf:li rdf:resource="http://www.infoq.com/presentations/apple-netty"/>
	<rdf:li rdf:resource="https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/"/>
	<rdf:li rdf:resource="https://github.com/raskasa/metrics-okhttp"/>
	<rdf:li rdf:resource="http://blog.cask.co/2015/12/introducing-netty-http-from-cask/"/>
	<rdf:li rdf:resource="http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/"/>
      </rdf:Seq>
    </items>
  </channel><item rdf:about="https://blog.nns.ee/2026/01/06/aike-ble/">
    <title>Reverse engineering my cloud-connected e-scooter and finding the master key to unlock all scooters</title>
    <dc:date>2026-01-16T15:10:07+00:00</dc:date>
    <link>https://blog.nns.ee/2026/01/06/aike-ble/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A great example of reverse engineering an Android app and Bluetooth IOT protocol using Frida and root access on an Android device:

<blockquote>Android exposes the Java classes android.bluetooth.BluetoothGatt and android.bluetooth.BluetoothGattCallback that apps are expected to use to use GATT characteristics. We can use Frida to hook into these and override many of the interesting functions. I was mostly interested in reads, writes and GATT notifications, so I whipped up a Frida script to hook into these and print all comms to the console [...]

The 20-byte value had me suspecting that SHA-1 was somehow being used. To confirm, I wrote another Frida script that hooks Android hashing functions exposed by the Java class java.security.MessageDigest [...]

The app uses Firebase for most of its cloud functionality. When signing in and pairing your scooter, the server sends the app a secret key. This is stored on the Android device, and can be read with root access.
</blockquote>
]]></description>
<dc:subject>frida reverse-engineering android firebase java kotlin gatt bluetooth react-native</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:30faa9bbc820/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:frida"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reverse-engineering"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:firebase"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kotlin"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gatt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bluetooth"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:react-native"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/2308.16862">
    <title>UltraLogLog</title>
    <dc:date>2025-03-25T10:21:11+00:00</dc:date>
    <link>https://arxiv.org/abs/2308.16862</link>
    <dc:creator>jm</dc:creator><description><![CDATA[_UltraLogLog: A Practical and More Space-Efficient Alternative to HyperLogLog for Approximate Distinct Counting_:

<blockquote>Since its invention HyperLogLog has become the standard algorithm for approximate distinct counting. Due to its space efficiency and suitability for distributed systems, it is widely used and also implemented in numerous databases. This work presents UltraLogLog, which shares the same practical properties as HyperLogLog. It is commutative, idempotent, mergeable, and has a fast guaranteed constant-time insert operation. At the same time, it requires 28% less space to encode the same amount of distinct count information, which can be extracted using the maximum likelihood method. Alternatively, a simpler and faster estimator is proposed, which still achieves a space reduction of 24%, but at an estimation speed comparable to that of HyperLogLog. In a non-distributed setting where martingale estimation can be used, UltraLogLog is able to reduce space by 17%. Moreover, its smaller entropy and its 8-bit registers lead to better compaction when using standard compression algorithms. All this is verified by experimental results that are in perfect agreement with the theoretical analysis which also outlines potential for even more space-efficient data structures. A production-ready Java implementation of UltraLogLog has been released as part of the open-source Hash4j library. </blockquote>

(via Tony Finch)]]></description>
<dc:subject>via:fanf algorithms data-structures hyperloglog ultraloglog counting count-distinct distinct approximation counts java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:a54e7c3c0b7d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hyperloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ultraloglog"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counting"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:count-distinct"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distinct"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:counts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Netflix/hollow">
    <title>Netflix/hollow</title>
    <dc:date>2025-02-25T12:19:14+00:00</dc:date>
    <link>https://github.com/Netflix/hollow</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
Hollow is a java library and toolset for disseminating in-memory datasets from a single producer to many consumers for high performance read-only access.

Hollow focuses narrowly on its prescribed problem set: keeping an entire, read-only dataset in-memory on consumers. It circumvents the consequences of updating and evicting data from a partial cache.

Due to its performance characteristics, Hollow shifts the scale in terms of appropriate dataset sizes for an in-memory solution. Datasets for which such liberation may never previously have been considered can be candidates for Hollow. For example, Hollow may be entirely appropriate for datasets which, if represented with json or XML, might require in excess of 100GB.
</blockquote>

Interesting approach, though possibly a bit scary in terms of circumventing the "keep things simple and boring" rule... still, a useful tool to have.]]></description>
<dc:subject>cache caching netflix java jvm memory hollow read-only architecture systems</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3f732f05411d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netflix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hollow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:read-only"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.jetbrains.com/blog/2024/04/04/full-line-code-completion-in-jetbrains-ides-all-you-need-to-know/#under-the-hood">
    <title>LLM-Driven Code Completion in JetBrains IDEs</title>
    <dc:date>2025-01-27T11:34:28+00:00</dc:date>
    <link>https://blog.jetbrains.com/blog/2024/04/04/full-line-code-completion-in-jetbrains-ides-all-you-need-to-know/#under-the-hood</link>
    <dc:creator>jm</dc:creator><description><![CDATA[JetBrains have come up with a new relatively-lightweight LLM-driven code generation option, constrained to producing single line suggestions:

<blockquote>
The length of the completion suggestions is a trade-off. While longer suggestions do tend to reduce how many keystrokes you have to make, which is good, they also increase the number of reviews required on your end. Taking the above into account, we decided that completing a single line of code would be a fair compromise.
</blockquote>

Some key features:

<blockquote>
- It works locally and is available offline. This means you can take advantage of the feature even if you aren’t connected to the internet.

- It doesn’t send any data from your machine over the internet. The language models that power full line code completion run locally, which is great for two reasons. First, your code remains safe, as it never leaves your machine. Second, there are no additional cloud-related expenses – that’s why this feature comes at no additional cost.
</blockquote>

Also, customer code is never used for training.

I've used this (in RubyMine), and found it fairly useful; it's good for generating the obvious next line, but is easily ignored when that's not what's needed. Not bad at all.]]></description>
<dc:subject>coding code-completion jetbrains ides java ruby llms ai code-generation rubymine intellij</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:87af374c576d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code-completion"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jetbrains"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ides"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:llms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ai"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code-generation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rubymine"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:intellij"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.infoq.com/presentations/optimizing-java-app-kubernetes/">
    <title>Optimizing Java Apps on Kubernetes</title>
    <dc:date>2025-01-23T14:45:35+00:00</dc:date>
    <link>https://www.infoq.com/presentations/optimizing-java-app-kubernetes/</link>
    <dc:creator>jm</dc:creator><description><![CDATA["Optimizing Java Applications on Kubernetes: beyond the Basics": Bruno Borges, at the InfoQ Dev Summit Boston, discusses the strategies for enhancing Java application performance on Kubernetes, focusing on leveraging JVM ergonomics, and managing garbage collection processes.  Some interesting tips here.]]></description>
<dc:subject>kubernetes java eks resources ops scaling scalability gc optimization jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c9522ab8d41/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:kubernetes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:eks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:resources"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/simdjson/simdjson-java">
    <title>simdjson/simdjson-java</title>
    <dc:date>2023-10-09T08:06:01+00:00</dc:date>
    <link>https://github.com/simdjson/simdjson-java</link>
    <dc:creator>jm</dc:creator><description><![CDATA["A Java version of simdjson" -- Java parsing using SIMD instructions to parse gigabytes of JSON per second.  Early days, requires Java 20, and only covers a small number of architectures, but it's getting there]]></description>
<dc:subject>simd java json parsing formats performance libraries</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:587e2c3aab0d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:json"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:parsing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:formats"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2">
    <title>The Black Magic of (Java) Method Dispatch</title>
    <dc:date>2023-04-11T21:03:19+00:00</dc:date>
    <link>https://shipilev.net/blog/2015/black-magic-method-dispatch/#_cheating_the_runtime_2</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some fascinating details of low-level Java performance optimization, particularly with JIT applied to OO method dispatch:

<blockquote>Programming languages like Java provide the facilities for subtyping/polymorphism as one of the ways to construct modular and reusable software. This language choice naturally comes at a price, since there is no hardware support for virtual calls, and therefore runtimes have to emulate this behavior. In many, many cases the performance of method dispatch is not important. Actually, in a vast majority of cases, the low-level performance concerns are not the real concerns.

However, there are cases when method dispatch performance is important, and there you need to understand how dispatch works, what runtimes optimize for you, and what you can do to cheat and/or emulate similar behavior in your code. For example, in the course of String Compression work, we were faced with the problem of selecting the coder for a given String. The obvious and highly maintainable approach of creating a Coder interface, a few implementations, and dispatching the virtual calls over it, had met some performance problems on the very tiny benchmarks. Therefore, we needed to contemplate something better. After a few experiments, this post was born as a reference for others who might try to do the same. This post also tangentially touches the inlining of virtual calls, as the natural thing during the optimization.</blockquote>

Discovered via this amazing commit: https://github.com/quarkusio/quarkus/commit/65dd4d43e2644db1c87726139280f9704140167c
]]></description>
<dc:subject>optimization performance java oo jit coding polymorphism</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fcc32a99ea26/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:polymorphism"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://krzysztofslusarski.github.io/2022/12/12/async-manual.html">
    <title>Async-profiler manual by use cases</title>
    <dc:date>2023-01-05T15:53:26+00:00</dc:date>
    <link>https://krzysztofslusarski.github.io/2022/12/12/async-manual.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Amazing collection of Java async-profiler commands and examples, each one representing a specific common (or not-so-common) use case we are liable to run into with production services: includes continuous profiling, wall-clock vs CPU, allocations, locks, cache misses, page faults, and thread-startup overhead]]></description>
<dc:subject>async-profiler java jvm profiling tracing performance tuning</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:8ec959433ae2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tracing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://twitter.com/nitsanw/status/1566677642748874753">
    <title>don't use JVM Flight Recorder profiling</title>
    <dc:date>2022-09-05T10:57:00+00:00</dc:date>
    <link>https://twitter.com/nitsanw/status/1566677642748874753</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Solid tip from Nitsan Wakart on Twitter:

<blockquote>If you are profiling for a CPU bottleneck [in java], DO NOT RELY ON JVM FLIGHT RECORDER METHOD PROFILING. Not even a little bit.

Use `async-profiler` for profiling(`-e cpu,lock,alloc`), with `--jfrsync default/profile` for extra JVM/JDK events.</blockquote>

]]></description>
<dc:subject>profiling java performance optimization jvm async-profiler via:twitter</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:acdfaf080f4b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async-profiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:twitter"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ulid/spec">
    <title>ULID</title>
    <dc:date>2022-06-13T10:06:43+00:00</dc:date>
    <link>https://github.com/ulid/spec</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A nice compact, readable, sortable unique ID string algorithm, eg. "01BX5ZZKBKACTAV9WEVGEMMVRZ" -- 128 bits, 1.21e+24 unique ULIDs per millisecond, case insensitive, with a URL safe character set. Very nice. (via Nelson)

There's a java implementation here: https://github.com/huxi/sulky/tree/master/sulky-ulid
]]></description>
<dc:subject>ulid uuid unique-ids java algorithms via:nelson unique ids</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:2c3939ba08e2/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ulid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uuid"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unique-ids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:nelson"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:unique"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ids"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/">
    <title>CVE-2022-21449: Psychic Signatures in Java</title>
    <dc:date>2022-04-20T09:29:49+00:00</dc:date>
    <link>https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Argh, this is a bad one:

<blockquote>Recent releases of Java were vulnerable to a similar kind of trick, in the implementation of widely-used ECDSA signatures. If you are running one of the vulnerable versions then an attacker can easily forge some types of SSL certificates and handshakes (allowing interception and modification of communications), signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages. All using the digital equivalent of a blank piece of paper.

It’s hard to overstate the severity of this bug. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys*) use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs.
</blockquote>]]></description>
<dc:subject>java jvm crypto security ecdsa webauthn saml jwt fail</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:19326f7fa161/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ecdsa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:webauthn"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:saml"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jwt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fail"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/resilience4j/resilience4j">
    <title>Resilience4J</title>
    <dc:date>2022-03-30T22:18:54+00:00</dc:date>
    <link>https://github.com/resilience4j/resilience4j</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a lightweight fault tolerance library inspired by Netflix Hystrix, but designed for Java 8 and functional programming.'
]]></description>
<dc:subject>fp hystrix java fault-tolerance retries timeouts architecture patterns circuit-breakers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3c49a9299497/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hystrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fault-tolerance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:retries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timeouts"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:patterns"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:circuit-breakers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/netty/netty/pull/10737/files">
    <title>SWAR indexOf byte search</title>
    <dc:date>2022-01-24T10:08:22+00:00</dc:date>
    <link>https://github.com/netty/netty/pull/10737/files</link>
    <dc:creator>jm</dc:creator><description><![CDATA[SIMD-Within-A-Register implementation of ByteBuf.indexOf() in Java, used in Netty. nice performance optimization technique]]></description>
<dc:subject>simd swar indexof bytebuffer java optimization performance search netty hacks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b1bb44f3ef08/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:swar"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:indexof"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bytebuffer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:search"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.vanillajava.blog/2022/01/distributed-unique-time-stamp.html">
    <title>Distributed Unique Time Stamp Identifiers</title>
    <dc:date>2022-01-06T10:28:00+00:00</dc:date>
    <link>https://blog.vanillajava.blog/2022/01/distributed-unique-time-stamp.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Peter Lawrey works out some performance numbers on high-performance Java unique ID generation]]></description>
<dc:subject>java ids uniqueness identifiers algorithms peter-lawrey performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:fc53ee7af57c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ids"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uniqueness"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:identifiers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:peter-lawrey"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://pkolaczk.github.io/overhead-of-optional/">
    <title>Overhead of Returning Optional Values in Java and Rust</title>
    <dc:date>2021-10-16T21:46:58+00:00</dc:date>
    <link>https://pkolaczk.github.io/overhead-of-optional/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[well, this is a little disappointing; even recent JVMs perform poorly in hotspots when Optional values are in use. Even nulls are not too good. tl;dr: primitives with "magic values" where needed are faster.]]></description>
<dc:subject>java rust optimization performance hotspots benchmarks optional null</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:950a505b2bef/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:rust"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hotspots"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optional"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:null"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.morling.dev/blog/fizzbuzz-simd-style/">
    <title>SIMD is coming to the JVM</title>
    <dc:date>2021-09-13T11:31:58+00:00</dc:date>
    <link>https://www.morling.dev/blog/fizzbuzz-simd-style/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[as of Java 16, incoming, there's a new IntVector, LongVector, ... et al set of classes to implement CPU-level vectorization instructions on x64 and AArch64 architectures ]]></description>
<dc:subject>simd performance java vectorization aarch64 x64</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7e62e6169542/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:simd"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:vectorization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aarch64"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:x64"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/Granulate/gprofiler">
    <title>gProfiler</title>
    <dc:date>2021-06-28T09:31:58+00:00</dc:date>
    <link>https://github.com/Granulate/gprofiler</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a system-wide profiler, combining multiple sampling profilers to produce unified visualization of what your CPU is spending time on.' -- claims to have little impact on performance of running code, supports Linux, java and Ruby]]></description>
<dc:subject>gprofiler profiling performance testing measurement coding ruby java linux perf via:reddit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6772a8b88a40/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gprofiler"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ruby"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linux"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:reddit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005577.html">
    <title>Defer disabling TLS 1.0/1.1 by default?</title>
    <dc:date>2021-04-06T10:03:30+00:00</dc:date>
    <link>https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-April/005577.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Colm MacCárthaigh:

<blockquote>
The short version is this:  we think about 1% of applications and
traffic "out there" are still using TLS1.0/TLS1.1. Given where
browsers are at, I think this percentage is an under-estimate of the
usage on Java applications - I suspect it's even higher there. When we
dig in with customers "Why are you still using TLS1.0 or TLS1.1" the
most common reasons are legacy appliances and applications. Think of
hardware load balancers that were never updated, or can't be, to
support TLS1.2 or better. Compliance mandated traffic inspection
devices that force TLS1.0 in certain industries are another reason.
For these applications, the change will break them, and they'll get a
low-level exception. The users can re-enable TLS1.0 and TLS1.1, but
they may suffer an outage because they likely weren't expecting a
breaking change low in the networking stack.
</blockquote>

]]></description>
<dc:subject>colmmacc java jdk tls ssl versioning backwards-compatibility internet</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7e92ac9a3e78/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:colmmacc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tls"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:versioning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backwards-compatibility"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:internet"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.testcontainers.org/">
    <title>Testcontainers</title>
    <dc:date>2021-03-18T09:49:47+00:00</dc:date>
    <link>https://www.testcontainers.org/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.</blockquote>

]]></description>
<dc:subject>docker java junit testing containers tests</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ab95f5fb86ea/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:junit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tests"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gceasy.io/">
    <title>GCEasy.io</title>
    <dc:date>2020-12-04T10:57:55+00:00</dc:date>
    <link>https://gceasy.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Java Garbage collection log analysis made easy: Industry's first machine learning guided Garbage collection log analysis tool. GCeasy has in-built intelligence to auto-detect problems in the JVM & Android GC logs and recommend solutions to it.'

Looks pretty simple to use, decent free tier.  Haven't tried it yet though....

]]></description>
<dc:subject>java gc tuning performance jvm logs ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d3d8327d2376/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:logs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/about-aws/whats-new/2020/09/aws-crt-http-client-in-aws-sdk-for-java-2x/">
    <title>AWS CRT HTTP Client in the AWS SDK for Java 2.x</title>
    <dc:date>2020-09-30T21:12:21+00:00</dc:date>
    <link>https://aws.amazon.com/about-aws/whats-new/2020/09/aws-crt-http-client-in-aws-sdk-for-java-2x/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting -- a new, high-performance, high-concurrency HTTP/1.1 client library in the AWS SDK, outperforming other Java HTTP client libs]]></description>
<dc:subject>java libraries aws http http-1.1 clients</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:21056a150feb/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http-1.1"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clients"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/apple/servicetalk/">
    <title>ServiceTalk</title>
    <dc:date>2019-11-06T14:00:14+00:00</dc:date>
    <link>https://github.com/apple/servicetalk/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a JVM network application framework with APIs tailored to specific protocols (e.g. HTTP/1.x, HTTP/2.x, etc…​) and supports multiple programming paradigms.
It is built on Netty and is designed to provide most of the performance/scalability benefits of Netty for common networking protocols used in service to service communication. ServiceTalk provides server support and "smart client" like features such as client-side load balancing and service discovery integration.</blockquote>

Open source from Apple.]]></description>
<dc:subject>apple servicetalk netty libraries java jvm coding http async</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d97f22fd741a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:servicetalk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.alluxio.io/blog/moving-from-apache-thrift-to-grpc-a-perspective-from-alluxio/">
    <title>Moving From Apache Thrift to gRPC: A Perspective From Alluxio</title>
    <dc:date>2019-06-27T09:21:18+00:00</dc:date>
    <link>https://www.alluxio.io/blog/moving-from-apache-thrift-to-grpc-a-perspective-from-alluxio/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good advice here:

<blockquote>Thrift served well as a fast and reliable RPC framework powering the metadata operations in Alluxio 1.x. Its limitation in handling streamed data has led us to a journey in search of better alternatives. gRPC provides some nice features that help us in building a simpler, more unified API layer. In this post, we discussed some lessons learned to move from Thrift to gRPC, including performance tuning tips that helped us achieve comparable performance for both one-off RPC calls as well as data streams. We hope this helps if you are looking at gRPC as an option for building high-performance services. Check out our blog for more articles on how we build Alluxio.</blockquote>

]]></description>
<dc:subject>thrift alluxio java grpc protocols coding netty</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5b7ff8c205dc/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:thrift"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:alluxio"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:grpc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:protocols"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://news.ycombinator.com/item?id=8099840">
    <title>jCenter is the new default repository used with Android's gradle plugin, I haven... | Hacker News</title>
    <dc:date>2019-06-24T10:10:07+00:00</dc:date>
    <link>https://news.ycombinator.com/item?id=8099840</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>I am a developer Advocate with JFrog, the company behind Bintray.

So, jcenter is a Java repository in Bintray (https://bintray.com/bintray/jcenter), which is the largest repo in the world for Java and Android OSS libraries, packages and components. All the content is served over a CDN, with a secure https connection. JCenter is the default repository in Groovy Grape 
(http://groovy.codehaus.org/Grape), built-in in Gradle (the jcenter() repository) and very easy to configure in every other build tool (maybe except Maven) and will become even easer very soon.

Bintray has a different approach to package identification than the legacy Maven Central. We don't rely on self-issued key-pairs (which can be generated to represent anyone, actually and never verified in Maven Central). Instead, similar to GitHub, Bintray gives a strong personal identity to any contributed library.

If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically.</blockquote>

]]></description>
<dc:subject>jars maven gradle java bintray via:lemire packaging distribution</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5fc8d137cd4f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gradle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bintray"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:lemire"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distribution"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/">
    <title>Spark memory tuning on EMR</title>
    <dc:date>2019-04-10T09:48:34+00:00</dc:date>
    <link>https://aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Best practices for successfully managing memory for Apache Spark applications on Amazon EMR', on the AWS Big Data blog.

'In this blog post, I detailed the possible out-of-memory errors, their causes, and a list of best practices to prevent these errors when submitting a Spark application on Amazon EMR.

My colleagues and I formed these best practices after thorough research and understanding of various Spark configuration properties and testing multiple Spark applications. These best practices apply to most of out-of-memory scenarios, though there might be some rare scenarios where they don’t apply. However, we believe that this blog post provides all the details needed so you can tweak parameters and successfully run a Spark application.']]></description>
<dc:subject>spark emr aws tuning memory ooms java</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:7d538a70d00d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:spark"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emr"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ooms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo">
    <title>Troubleshooting Problems With Native (Off-Heap) Memory in Java Applications</title>
    <dc:date>2019-03-22T15:03:45+00:00</dc:date>
    <link>https://dzone.com/articles/troubleshooting-problems-with-native-off-heap-memo</link>
    <dc:creator>jm</dc:creator><description><![CDATA[quite good advice on dealing with memory problems caused by off-heap DirectByteBuffers in java 8.

'Furthermore, the JDK caches one or more DirectByteBuffers per thread, and by default, there is no limit on the number or size of these buffers. As a result, if a Java app creates many threads that perform I/O using HeapByteBuffers, and/or these buffers are big, the JVM process may end up using a lot of additional native memory that looks like a leak'.

'java.lang.OutOfMemoryError: Direct buffer memory' is the indicative error message.]]></description>
<dc:subject>java off-heap buffers memory memory-leaks gc jdk ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:cc36a7f2cf9b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:buffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://arxiv.org/abs/1902.04023">
    <title>[1902.04023] Computing Extremely Accurate Quantiles Using t-Digests</title>
    <dc:date>2019-02-18T11:05:52+00:00</dc:date>
    <link>https://arxiv.org/abs/1902.04023</link>
    <dc:creator>jm</dc:creator><description><![CDATA['We present on-line algorithms for computing approximations of rank-based statistics that give high accuracy, particularly near the tails of a distribution, with very small sketches. Notably, the method allows a quantile q to be computed with an accuracy relative to max(q,1−q) rather than absolute accuracy as with most other methods. This new algorithm is robust with respect to skewed distributions or ordered datasets and allows separately computed summaries to be combined with no loss in accuracy.  An open-source Java implementation of this algorithm is available from the author. Independent implementations in Go and Python are also available.'

(via Tony Finch)]]></description>
<dc:subject>java go python open-source quantiles percentiles approximation statistics sketching algorithms via:fanf</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6c84ec8a0947/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:go"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:python"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:approximation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sketching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:via:fanf"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/java-bytebuffer-leak.html">
    <title>Java's ByteBuffer native memory &quot;leak&quot;</title>
    <dc:date>2018-11-19T11:30:30+00:00</dc:date>
    <link>http://www.evanjones.ca/java-bytebuffer-leak.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Well this is suboptimal:

<blockquote>The Java NIO APIs use ByteBuffers as the source and destination of I/O calls, and come in two flavours. Heap ByteBuffers wrap a byte[] array, allocated in the garbage collected Java heap. Direct ByteBuffers wrap memory allocated outside the Java heap using malloc. Only "native" memory can be passed to operating system calls, so it won't be moved by the garbage collector. This means that when you use a heap ByteBuffer for I/O, it is copied into a temporary direct ByteBuffer. The JDK caches one temporary buffer per thread, without any memory limits. As a result, if you call I/O methods with large heap ByteBuffers from multiple threads, your process can use a huge amount of additional native memory, which looks like a native memory leak. This can cause your process to unexpectedly run into memory limits and get killed.</blockquote>

]]></description>
<dc:subject>jvm performance java memory leaks bytebuffers netty threads coding bugs</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:94c60cf2a090/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bytebuffers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.jetbrains.com/upsource/2016/08/03/what-to-look-for-in-java-8-code/">
    <title>What to Look for in Java 8 Code</title>
    <dc:date>2018-10-05T12:13:30+00:00</dc:date>
    <link>https://blog.jetbrains.com/upsource/2016/08/03/what-to-look-for-in-java-8-code/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Great advice from Trisha Gee on J8 features and how to code-review code which uses them]]></description>
<dc:subject>java8 java code-review coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4bdd8929bf47/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:code-review"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-11-trap.html">
    <title>Do not fall into Oracle's Java 11 trap</title>
    <dc:date>2018-09-26T15:29:06+00:00</dc:date>
    <link>https://blog.joda.org/2018/09/do-not-fall-into-oracles-java-11-trap.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>The key part of the terms is as follows:

You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;

The trap is as follows:

Download Oracle JDK (because that is what you've always done, and it is what the web-search tells you);
Use it in production (because you didn't realise the license changed);
Get a nasty phone call from Oracle's license enforcement teams demanding lots of money

In other words, Oracle can rely on inertia from Java developers to cause them to download the wrong (commercial) release of Java. Unless you read the text/warnings/legalese very carefully you might not even realise Oracle JDK is now commercial, and that you are therefore liable to pay Oracle for Java.

</blockquote>

]]></description>
<dc:subject>java licensing openjdk open-source oracle software jdk jre</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:f8b03b43714b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:licensing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:openjdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:open-source"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oracle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:software"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jdk"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jre"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://security.googleblog.com/2018/08/introducing-tink-cryptographic-software.html">
    <title>Google Online Security Blog: Introducing the Tink cryptographic software library</title>
    <dc:date>2018-08-30T21:25:04+00:00</dc:date>
    <link>https://security.googleblog.com/2018/08/introducing-tink-cryptographic-software.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Tink aims to provide cryptographic APIs that are secure, easy to use correctly, and hard(er) to misuse. Tink is built on top of existing libraries such as BoringSSL and Java Cryptography Architecture, but includes countermeasures to many weaknesses in these libraries, which were discovered by Project Wycheproof, another project from our team.
With Tink, many common cryptographic operations such as data encryption, digital signatures, etc. can be done with only a few lines of code. </blockquote>

]]></description>
<dc:subject>tink google java c++ boringssl ssl jca crypto</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6a051e37ba48/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tink"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:c++"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:boringssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ssl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jca"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:crypto"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/spotify/dockerfile-maven">
    <title>spotify/dockerfile-maven: A set of Maven tools for dealing with Dockerfiles</title>
    <dc:date>2018-08-22T09:14:31+00:00</dc:date>
    <link>https://github.com/spotify/dockerfile-maven</link>
    <dc:creator>jm</dc:creator><description><![CDATA['a Maven plugin and extension which help to seamlessly integrate Docker with Maven.  The design goals are:

Don't try to do anything fancy. Dockerfiles are how you build Docker projects; that's what this plugin uses. They are mandatory.

Make the Docker build process integrate with the Maven build process. If you bind the default phases, when you type mvn package, you get a Docker image. When you type mvn deploy, your image gets pushed.

Make the goals remember what you are doing. You can type mvn dockerfile:build and later mvn dockerfile:tag and later mvn dockerfile:push without problems. This also eliminates the need for something like mvn dockerfile:build -DalsoPush; instead you can just say mvn dockerfile:build dockerfile:push.

Integrate with the Maven build reactor. You can depend on the Docker image of one project in another project, and Maven will build the projects in the correct order. This is useful when you want to run integration tests involving multiple services.'

Looks very nice and well-run -- shame it's Maven instead of Gradle...]]></description>
<dc:subject>java docker maven build coding packaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6e9446908fe4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html">
    <title>Google Cloud Platform Blog: Introducing Jib</title>
    <dc:date>2018-07-10T16:04:31+00:00</dc:date>
    <link>https://cloudplatform.googleblog.com/2018/07/introducing-jib-build-java-docker-images-better.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA['build Java Docker images better':

<blockquote>Jib takes advantage of layering in Docker images and integrates with your build system to optimize Java container image builds in the following ways:

Simple - Jib is implemented in Java and runs as part of your Maven or Gradle build. You do not need to maintain a Dockerfile, run a Docker daemon, or even worry about creating a fat JAR with all its dependencies. Since Jib tightly integrates with your Java build, it has access to all the necessary information to package your application. Any variations in your Java build are automatically picked up during subsequent container builds.

Fast - Jib takes advantage of image layering and registry caching to achieve fast, incremental builds. It reads your build config, organizes your application into distinct layers (dependencies, resources, classes) and only rebuilds and pushes the layers that have changed. When iterating quickly on a project, Jib can save valuable time on each build by only pushing your changed layers to the registry instead of your whole application.

Reproducible - Jib supports building container images declaratively from your Maven and Gradle build metadata, and as such can be configured to create reproducible build images as long as your inputs remain the same.</blockquote>

]]></description>
<dc:subject>build google java docker maven gradle coding builds jars fat-jars packaging</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b5d92c0dff8b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gradle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:builds"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fat-jars"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/airlift/jvmkill/blob/master/README.md">
    <title>airlift/jvmkill</title>
    <dc:date>2018-07-05T09:29:02+00:00</dc:date>
    <link>https://github.com/airlift/jvmkill/blob/master/README.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>a simple JVMTI agent that forcibly terminates the JVM when it is unable to allocate memory or create a thread. This is important for reliability purposes: an OutOfMemoryError will often leave the JVM in an inconsistent state. Terminating the JVM will allow it to be restarted by an external process manager.</blockquote>

This is apparently still useful despite the existence of '-XX:ExitOnOutOfMemoryError' as of java 8, since that may somehow still fail occasionally.]]></description>
<dc:subject>oom java reliability uptime memory ops</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:db2c1986f022/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oom"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:reliability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:uptime"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html">
    <title>How to change JVM arguments at runtime to avoid application restart</title>
    <dc:date>2018-06-06T15:27:52+00:00</dc:date>
    <link>https://confluence.atlassian.com/kb/how-to-change-jvm-arguments-at-runtime-to-avoid-application-restart-816682109.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is a super nifty feature of the JVM: turn on and off heap class histogram dumps at runtime, for instance.

<blockquote>java -XX:+PrintFlagsFinal -version|grep manageable</blockquote>

]]></description>
<dc:subject>jvm ops switches cli java heap-dumps memory debugging memory-leaks</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:b591a243dc1d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:switches"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cli"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap-dumps"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/lemire/JavaFastPFOR">
    <title>lemire/JavaFastPFOR: A simple integer compression library in Java</title>
    <dc:date>2018-04-09T15:39:37+00:00</dc:date>
    <link>https://github.com/lemire/JavaFastPFOR</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>
a library to compress and uncompress arrays of integers very fast. The assumption is that most (but not all) values in your array use much less than 32 bits, or that the gaps between the integers use much less than 32 bits. These sort of arrays often come up when using differential coding in databases and information retrieval (e.g., in inverted indexes or column stores).

Please note that random integers are not compressible, by this library or by any other means. If you ever had the means of systematically compressing random integers, you could compress any data source to nothing, by recursive application of your technique.

This library can decompress integers at a rate of over 1.2 billions per second (4.5 GB/s). It is significantly faster than generic codecs (such as Snappy, LZ4 and so on) when compressing arrays of integers.

The library is used in LinkedIn Pinot, a realtime distributed OLAP datastore. Part of this library has been integrated in Parquet (http://parquet.io/). A modified version of the library is included in the search engine Terrier (http://terrier.org/). This libary is used by ClueWeb Tools (https://github.com/lintool/clueweb). It is also used by Apache NiFi.</blockquote>

]]></description>
<dc:subject>compression java pfor encoding integers algorithms storage</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:79294351fa68/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:pfor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:encoding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:integers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://lemire.me/blog/2018/03/13/iterating-over-hash-sets-quickly-in-java/">
    <title>Iterating over hash sets quickly in Java</title>
    <dc:date>2018-03-13T22:21:26+00:00</dc:date>
    <link>https://lemire.me/blog/2018/03/13/iterating-over-hash-sets-quickly-in-java/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting datum:
<blockquote>My numbers are clear: in my tests, it is three times faster to sum up the values in a LinkedHashSet [than a HashSet].</blockquote>

]]></description>
<dc:subject>performance java locality memory cache-friendly data-structures hashsets linkedhashsets sets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:18a5574bcbd0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locality"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cache-friendly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashsets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkedhashsets"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/airlift/aircompressor">
    <title>airlift/aircompressor: A port of Snappy, LZO and LZ4 to Java</title>
    <dc:date>2018-01-30T17:35:19+00:00</dc:date>
    <link>https://github.com/airlift/aircompressor</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This library contains implementations of LZ4, Snappy, and LZO written in pure Java. They are typically 10-40% faster than the JNI wrapper for the native libraries.</blockquote>

]]></description>
<dc:subject>lz4 lzo lzop snappy java libraries airlift compression performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ff75bb45fa1f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lz4"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lzo"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lzop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:snappy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:airlift"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:compression"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/pmem/pcj/blob/master/README.md">
    <title>Intel pcj library for persistent memory-oriented data structures</title>
    <dc:date>2017-10-03T09:25:17+00:00</dc:date>
    <link>https://github.com/pmem/pcj/blob/master/README.md</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>This is a "pilot" project to develop a library for Java objects stored in persistent memory. Persistent collections are being emphasized because many applications for persistent memory seem to map well to the use of collections. One of this project's goals is to make programming with persistent objects feel natural to a Java developer, for example, by using familiar Java constructs when incorporating persistence elements such as data consistency and object lifetime.

The breadth of persistent types is currently limited and the code is not performance-optimized. We are making the code available because we believe it can be useful in experiments to retrofit existing Java code to use persistent memory and to explore persistent Java programming in general.</blockquote>

(via Mario Fusco)]]></description>
<dc:subject>persistent-memory data-structures storage persistence java coding future</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:3fa9ddfacc22/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:persistent-memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:storage"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:persistence"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:future"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ">
    <title>Locking, Little's Law, and the USL</title>
    <dc:date>2017-09-20T14:36:55+00:00</dc:date>
    <link>https://groups.google.com/forum/#!msg/mechanical-sympathy/gchG_oQ_kQM/59BDMOdUAwAJ</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent explanatory mailing list post by Martin Thompson to the mechanical-sympathy group, discussing Little's Law vs the USL:

<blockquote>Little's law can be used to describe a system in steady state from a queuing perspective, i.e. arrival and leaving rates are balanced. In this case it is a crude way of modelling a system with a contention percentage of 100% under Amdahl's law, in that throughput is one over latency.

However this is an inaccurate way to model a system with locks. Amdahl's law does not account for coherence costs. For example, if you wrote a microbenchmark with a single thread to measure the lock cost then it is much lower than in a multi-threaded environment where cache coherence, other OS costs such as scheduling, and lock implementations need to be considered.

Universal Scalability Law (USL) accounts for both the contention and the coherence costs.
http://www.perfdynamics.com/Manifesto/USLscalability.html

When modelling locks it is necessary to consider how contention and coherence costs vary given how they can be implemented. Consider in Java how we have biased locking, thin locks, fat locks, inflation, and revoking biases which can cause safe points that bring all threads in the JVM to a stop with a significant coherence component.</blockquote>

]]></description>
<dc:subject>usl scaling scalability performance locking locks java jvm amdahls-law littles-law system-dynamics modelling systems caching threads schedulers contention</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d64fb1279a0b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scaling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:locks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:amdahls-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:system-dynamics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:modelling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:systems"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:caching"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threads"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:schedulers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:contention"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html">
    <title>Native Memory Tracking</title>
    <dc:date>2017-09-18T09:35:48+00:00</dc:date>
    <link>https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Java 8 HotSpot feature to monitor and diagnose native memory leaks]]></description>
<dc:subject>java jvm memory native-memory malloc debugging coding nmt java-8 jcmd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d2f2bae02fb3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:native-memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nmt"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java-8"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jcmd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html">
    <title>Java Flame Graphs Introduction: Fire For Everyone!</title>
    <dc:date>2017-09-11T10:48:52+00:00</dc:date>
    <link>http://psy-lob-saw.blogspot.ie/2017/02/flamegraphs-intro-fire-for-everyone.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[lots of good detail on flame graph usage in Java, and the Honest Profiler (honest because it's safepoint-free)]]></description>
<dc:subject>profiling java safepoints jvm flame-graphs perf measurement benchmarking testing</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:1a6f8c8d9b75/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:profiling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:safepoints"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:flame-graphs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:perf"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:testing"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/AdoptOpenJDK/jitwatch">
    <title>AdoptOpenJDK/jitwatch</title>
    <dc:date>2017-08-24T16:22:31+00:00</dc:date>
    <link>https://github.com/AdoptOpenJDK/jitwatch</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>Log analyser and visualiser for the HotSpot JIT compiler. Inspect inlining decisions, hot methods, bytecode, and assembly. View results in the JavaFX user interface.</blockquote>

]]></description>
<dc:subject>analysis java jvm performance tools debugging optimization jit</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:404ca57f5933/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://plasma-umass.github.io/doppio-demo/">
    <title>DoppioJVM</title>
    <dc:date>2017-07-12T10:53:58+00:00</dc:date>
    <link>https://plasma-umass.github.io/doppio-demo/</link>
    <dc:creator>jm</dc:creator><description><![CDATA['A Java Virtual Machine written in 100% JavaScript.'  Wrapping outbound TCP traffic in websockets, mad stuff]]></description>
<dc:subject>jvm java javascript js hacks browser emulation websockets</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:15ebe75eae91/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:javascript"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:js"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hacks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:browser"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:emulation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:websockets"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76?__s=gf36pf8g1gjugcqh6ppo">
    <title>How does language, memory and package size affect cold starts of AWS Lambda?</title>
    <dc:date>2017-06-19T15:32:19+00:00</dc:date>
    <link>https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76?__s=gf36pf8g1gjugcqh6ppo</link>
    <dc:creator>jm</dc:creator><description><![CDATA[some datapoints -- java and C# have a hard time]]></description>
<dc:subject>java cold-start lambda serverless aws</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:4bb0f99fa5ce/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cold-start"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lambda"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serverless"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aws"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://codahale.com/usl4j-and-you/">
    <title>usl4j And You | codahale.com</title>
    <dc:date>2017-06-01T10:08:29+00:00</dc:date>
    <link>https://codahale.com/usl4j-and-you/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Coda Hale wrote a handy java library implementing a USL solver]]></description>
<dc:subject>usl scalability java performance optimization benchmarking measurement ops coda-hale</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c184c035e80a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:usl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:optimization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:benchmarking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:measurement"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coda-hale"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://shipilev.net/jvm-anatomy-park/10-string-intern/">
    <title>don't use String.intern() in Java</title>
    <dc:date>2017-05-15T10:23:27+00:00</dc:date>
    <link>https://shipilev.net/jvm-anatomy-park/10-string-intern/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>String.intern is the gateway to native JVM String table, and it comes with caveats: throughput, memory footprint, pause time problems will await the users. Hand-rolled deduplicators/interners to reduce memory footprint are working much more reliably, because they are working on Java side, and also can be thrown away when done. GC-assisted String deduplication does alleviate things even more. In almost every project we were taking care of, removing String.intern from the hotpaths was the very profitable performance optimization. Do not use it without thinking, okay?</blockquote>

]]></description>
<dc:subject>strings interning java performance tips</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:936351988ed0/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:strings"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:interning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tips"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://ercoppa.github.io/HadoopInternals/">
    <title>Hadoop Internals</title>
    <dc:date>2017-02-17T14:39:34+00:00</dc:date>
    <link>http://ercoppa.github.io/HadoopInternals/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[This is the best documentation on the topic I've seen in a while]]></description>
<dc:subject>hadoop map-reduce architecture coding java distcomp</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5e96fe6a92a4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hadoop"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:map-reduce"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:distcomp"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.evanjones.ca/java-native-leak-bug.html">
    <title>Debugging Java Native Memory Leaks (evanjones.ca)</title>
    <dc:date>2017-01-10T16:39:09+00:00</dc:date>
    <link>http://www.evanjones.ca/java-native-leak-bug.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Using jemalloc to instrument the contents of the native heap and record stack traces of each chunk's allocators, so that leakers can be quickly identified (GZIPInputStream in this case).

See also https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/ , https://github.com/jeffgriffith/native-jvm-leaks/blob/master/README.md .]]></description>
<dc:subject>debugging memory jvm java leaks memory-leaks leak-checking jemalloc malloc native heap off-heap gzipinputstream</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5206aa65dc43/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory-leaks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:leak-checking"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:malloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:native"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gzipinputstream"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/tdunning/t-digest">
    <title>tdunning/t-digest</title>
    <dc:date>2016-12-12T12:28:16+00:00</dc:date>
    <link>https://github.com/tdunning/t-digest</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>A new data structure for accurate on-line accumulation of rank-based statistics such as quantiles and trimmed means. The t-digest algorithm is also very parallel friendly making it useful in map-reduce and parallel streaming applications.

The t-digest construction algorithm uses a variant of 1-dimensional k-means clustering to product a data structure that is related to the Q-digest. This t-digest data structure can be used to estimate quantiles or compute other rank statistics. The advantage of the t-digest over the Q-digest is that the t-digest can handle floating point values while the Q-digest is limited to integers. With small changes, the t-digest can handle any values from any ordered set that has something akin to a mean. The accuracy of quantile estimates produced by t-digests can be orders of magnitude more accurate than those produced by Q-digests in spite of the fact that t-digests are more compact when stored on disk.</blockquote>

Super-nice feature is that it's mergeable, so amenable to parallel usage across multiple hosts if required.  Java implementation, ASL licensing.]]></description>
<dc:subject>data-structures algorithms java t-digest statistics quantiles percentiles aggregation digests estimation ranking</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:aaf9fb613f21/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:t-digest"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:statistics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:quantiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:percentiles"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:aggregation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:digests"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:estimation"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ranking"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.slideshare.net/dbryant_uk/j1-2015-debugging-java-apps-in-containers-no-heavy-welding-gear-required">
    <title>J1 2015 &quot;Debugging Java Apps in Containers: No Heavy Welding Gear Required&quot;</title>
    <dc:date>2016-09-13T10:05:50+00:00</dc:date>
    <link>http://www.slideshare.net/dbryant_uk/j1-2015-debugging-java-apps-in-containers-no-heavy-welding-gear-required</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Some good slides with tips on running java apps in production in Docker]]></description>
<dc:subject>java docker ops containers</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:80ba8c32a215/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:containers"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.loggly.com/blog/lessons-learned-from-using-regexes-at-scale/">
    <title>Lessons Learned from Using Regexes At Scale</title>
    <dc:date>2016-09-06T14:40:15+00:00</dc:date>
    <link>https://www.loggly.com/blog/lessons-learned-from-using-regexes-at-scale/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[great post from Loggly on production usage of regular expressions on shared, multitenant architecture, where a /.*/ can really screw things up. "NFA isn't a golden ticket" paragraph included]]></description>
<dc:subject>loggly regexp regexes java dfa nfa architecture</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ac8a514b7bc3/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:loggly"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regexp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:regexes"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dfa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:nfa"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:architecture"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://groups.google.com/forum/#!topic/mechanical-sympathy/Ko8osOYLq4I">
    <title>Unchecked exceptions for IO considered harmful - Google Groups</title>
    <dc:date>2016-08-16T16:23:09+00:00</dc:date>
    <link>https://groups.google.com/forum/#!topic/mechanical-sympathy/Ko8osOYLq4I</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Insightful thread from the mechanical sympathy group, regarding the checked-vs-unchecked style question:

<blockquote>Peter Lawrey: Our view is that Checked Exception makes more sense for library writers as they can explicitly pass off errors to the caller. As a caller, especially if you are new to a product, you don't understand the exceptions or what you can do about them.  They add confusion.

For this reason we use checked exceptions internally in the lower layers and try to avoid passing them in our higher level interfaces.  Note: A high percentage of our fall backs are handling iOExceptons and recovering from them. [....]

My experience is that the more complex and layered your libraries the more essential checked exceptions become.  I see them as essential for scalability of your software.
</blockquote>

]]></description>
<dc:subject>exceptions java style coding checked-exceptions ioexceptions io error-handling</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:53173a73b67b/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:style"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:checked-exceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ioexceptions"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:io"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:error-handling"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/">
    <title>Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars</title>
    <dc:date>2016-06-18T09:46:44+00:00</dc:date>
    <link>https://blog.buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Reducing service memory usage from 500MB to 105MB:

<blockquote>We found two specific techniques to be the most beneficial: turning off one of the two JIT compilers enabled by default (the “C2” compiler), and using a 32-bit, rather than a 64-bit, JVM.</blockquote>

]]></description>
<dc:subject>32bit jvm java ops memory tuning jit linkerd</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:ade3b2e45f61/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:32bit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ops"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:tuning"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jit"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:linkerd"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ztellman/dirigiste">
    <title>ztellman/dirigiste</title>
    <dc:date>2016-06-01T11:55:13+00:00</dc:date>
    <link>https://github.com/ztellman/dirigiste</link>
    <dc:creator>jm</dc:creator><description><![CDATA['centrally-planned object and thread pools' for java.

'In the default JVM thread pools, once a thread is created it will only be retired when it hasn't performed a task in the last minute. In practice, this means that there are as many threads as the peak historical number of concurrent tasks handled by the pool, forever. These thread pools are also poorly instrumented, making it difficult to tune their latency or throughput.  Dirigiste provides a fast, richly instrumented version of a java.util.concurrent.ExecutorService, and provides a means to feed that instrumentation into a control mechanism that can grow or shrink the pool as needed. Default implementations that optimize the pool size for thread utilization are provided.  It also provides an object pool mechanism that uses a similar feedback mechanism to resize itself, and is significantly simpler than the Apache Commons object pool implementation.'

Great metric support, too.]]></description>
<dc:subject>async jvm dirigiste java threadpools concurrency utilization capacity executors object-pools object-pooling latency</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5092c7f0c12e/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dirigiste"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:utilization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:executors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:object-pooling"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:latency"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://koloboke.com/">
    <title>Koloboke Collections</title>
    <dc:date>2016-05-31T14:54:10+00:00</dc:date>
    <link>https://koloboke.com/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Interesting new collections lib for Java 6+; generates Map-like and Set-like collections at runtime based on the contract annotations you desire.  Fat (20MB) library-based implementation also available]]></description>
<dc:subject>collections java koloboke performance coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:9a6a988b787c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:collections"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:koloboke"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://motherboard.vice.com/read/why-the-very-silly-oracle-v-google-trial-actually-matters">
    <title>Why the Very Silly Oracle v. Google Trial Actually Matters</title>
    <dc:date>2016-05-26T15:19:01+00:00</dc:date>
    <link>http://motherboard.vice.com/read/why-the-very-silly-oracle-v-google-trial-actually-matters</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>If it’s illegal to write clean room implementations of APIs, then no one has clean hands. The now-shelved open source project Apache Harmony, like Android, reimplemented Java SE, and tech giant IBM contributed code to that project. Oracle itself built its business off a proprietary implementation of SQL, which was created by IBM.  The proposition “Reimplementations of APIs are infringements” creates a recursive rabbit hole of liability that spans across the industry. Even the very 37 Java APIs at issue in this trial contain reimplementations of other APIs. Google witness Joshua Bloch—who, while at Sun Microsystems, wrote many of the Java APIs—testified that specific Java APIs are reimplementations of other APIs from Perl 5 and the C programming language.</blockquote>

]]></description>
<dc:subject>apis fair-use copyright ip android java google oracle law</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:dfc223222b1d/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:fair-use"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:copyright"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:android"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:google"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oracle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/uber-common/infer-plugin">
    <title>uber-common/infer-plugin</title>
    <dc:date>2016-05-17T13:11:47+00:00</dc:date>
    <link>https://github.com/uber-common/infer-plugin</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Gradle plugin that allows easy integration with the infer static analyzer]]></description>
<dc:subject>infer java static-analysis bugs coding null</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:445c127fd3da/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:static-analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:bugs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:null"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://motherboard.vice.com/read/in-google-v-oracle-the-nerds-are-getting-owned">
    <title>In Oracle v. Google, a Nerd Subculture Is on Trial</title>
    <dc:date>2016-05-13T14:26:51+00:00</dc:date>
    <link>http://motherboard.vice.com/read/in-google-v-oracle-the-nerds-are-getting-owned</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>“The G part stands for GNU?” Alsup asked in disbelief.
“Yes,” said Schwartz on the stand.
“That doesn’t make any sense,” said the 71-year-old Clinton appointee.</blockquote>

]]></description>
<dc:subject>law gnu gpl licensing java oracle sun apis ip</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:122f28325fe9/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gnu"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gpl"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:licensing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:oracle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:sun"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:ip"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/">
    <title>Using jemalloc to get to the bottom of an off-heap Java memory leak</title>
    <dc:date>2016-04-14T11:39:20+00:00</dc:date>
    <link>https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Good technique]]></description>
<dc:subject>debugging java jvm memory jemalloc off-heap</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:e8651207606c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:debugging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:memory"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jemalloc"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:off-heap"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://jitpack.io/">
    <title>JitPack</title>
    <dc:date>2016-04-04T09:53:25+00:00</dc:date>
    <link>https://jitpack.io/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Publish JVM and Android libraries direct from github -- it'll build and package a lib on the fly, caching them via CDN]]></description>
<dc:subject>build github java maven gradle dependencies packaging libraries</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:0c48d5efec3f/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:build"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:github"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:maven"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:gradle"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dependencies"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:packaging"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:libraries"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/ifesdjeen/hashed-wheel-timer">
    <title>Hashed Wheel Timer</title>
    <dc:date>2016-03-29T12:02:43+00:00</dc:date>
    <link>https://github.com/ifesdjeen/hashed-wheel-timer</link>
    <dc:creator>jm</dc:creator><description><![CDATA[nice java impl of this efficient data structure, broken out from Project Reactor
]]></description>
<dc:subject>scalability java timers hashed-wheel-timers algorithms data-structures</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:6139ec69af2a/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:scalability"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hashed-wheel-timers"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/JCTools/JCTools/pull/93">
    <title>Wait and lock free alternatives to LongAdder and AtomicLong by qwwdfsad</title>
    <dc:date>2016-03-14T17:32:46+00:00</dc:date>
    <link>https://github.com/JCTools/JCTools/pull/93</link>
    <dc:creator>jm</dc:creator><description><![CDATA[interesting new lock-free low-level hacking]]></description>
<dc:subject>longadder doug-lea mechanical-sympathy lock-free performance atomic multithreading java jvm</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:28819375e2f4/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:longadder"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:doug-lea"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:mechanical-sympathy"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lock-free"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:atomic"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:multithreading"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/conversant/disruptor">
    <title>Conversant ConcurrentQueue and Disruptor BlockingQueue</title>
    <dc:date>2016-03-07T11:24:20+00:00</dc:date>
    <link>https://github.com/conversant/disruptor</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Disruptor is the highest performing intra-thread transfer mechanism available in Java. Conversant Disruptor is the highest performing implementation of this type of ring buffer queue because it has almost no overhead and it exploits a particularly simple design.

Conversant has been using this in production since 2012 and the performance is excellent. The BlockingQueue implementation is very stable, although we continue to tune and improve it.  The latest release, 1.2.4, is 100% production ready.

Although we have been working on it for a long time, we decided to open source our BlockingQueue this year to contribute something back to the community. ... its a drop in for BlockingQueue, so its a very easy test.  Conversant Disruptor will crush ArrayBlockingQueue and LinkedTransferQueue for thread to thread transfers.    

In our system, we noticed a 10-20% reduction in overall system load and latency when we introduced it.']]></description>
<dc:subject>disruptor blocking-queues queues queueing data-structures algorithms java conversant concurrency performance</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:502056282b58/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:disruptor"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:blocking-queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queues"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:queueing"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:data-structures"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:algorithms"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:conversant"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:performance"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.lolware.net/2016/02/12/argon2-code-review.html">
    <title>Argon2 code audits - part one - Infer</title>
    <dc:date>2016-02-23T17:24:29+00:00</dc:date>
    <link>https://www.lolware.net/2016/02/12/argon2-code-review.html</link>
    <dc:creator>jm</dc:creator><description><![CDATA[A pretty viable way to run Facebook's Infer dataflow static analysis tool (which is otherwise quite a bear to run).]]></description>
<dc:subject>infer facebook java clang errors static-analysis lint dataflow docker</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5e2f76232714/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:infer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:facebook"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clang"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:errors"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:static-analysis"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:lint"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dataflow"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:docker"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://www.infoq.com/presentations/apple-netty">
    <title>Netty @Apple: Large Scale Deployment/Connectivity [video]</title>
    <dc:date>2016-01-08T10:04:43+00:00</dc:date>
    <link>http://www.infoq.com/presentations/apple-netty</link>
    <dc:creator>jm</dc:creator><description><![CDATA['Norman Maurer presents how Apple uses Netty for its Java based services and the challenges of doing so, including how they enhanced performance by participating in the Netty open source community. Maurer takes a deep dive into advanced topics like JNI, JVM internals, and others.']]></description>
<dc:subject>apple netty norman-maurer java jvm async talks presentations</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:09aa5e33f478/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:apple"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:norman-maurer"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:async"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:talks"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:presentations"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/">
    <title>The Importance of Tuning Your Thread Pools</title>
    <dc:date>2016-01-04T10:42:16+00:00</dc:date>
    <link>https://www.voxxed.com/blog/2015/12/importance-tuning-thread-pools/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Excellent blog post on thread pools, backpressure, Little's Law, and other Hystrix-related topics (PS: use Hystrix)]]></description>
<dc:subject>hystrix threadpools concurrency java jvm backpressure littles-law capacity</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:d8e4a0101363/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:hystrix"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:threadpools"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:concurrency"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jvm"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:backpressure"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:littles-law"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:capacity"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="https://github.com/raskasa/metrics-okhttp">
    <title>raskasa/metrics-okhttp</title>
    <dc:date>2015-12-31T10:27:43+00:00</dc:date>
    <link>https://github.com/raskasa/metrics-okhttp</link>
    <dc:creator>jm</dc:creator><description><![CDATA[Metrics integration for OkHttp. looks quite nice]]></description>
<dc:subject>okhttp java clients http metrics dropwizard</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:5576ec805c35/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:okhttp"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:clients"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:metrics"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:dropwizard"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://blog.cask.co/2015/12/introducing-netty-http-from-cask/">
    <title>Introducing Netty-HTTP from Cask</title>
    <dc:date>2015-12-03T12:52:22+00:00</dc:date>
    <link>http://blog.cask.co/2015/12/introducing-netty-http-from-cask/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[<blockquote>netty-http library solves [Netty usability issues] by using JAX-RS annotations to build a HTTP path routing layer on top of netty. In addition, the library implements a guava service to manage the HTTP service. netty-http allows users of the library to just focus on writing the business logic in HTTP handlers without having to worry about the complexities of path routing or learning netty pipeline internals to build the HTTP service.</blockquote>

We've written something very similar, although I didn't even bother supporting JAX-RS annotations -- just a simple code-level DSL.]]></description>
<dc:subject>jax-rs netty http cask java services coding</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c5c91942c05c/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jax-rs"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:netty"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:http"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:cask"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:services"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:coding"/>
</rdf:Bag></taxo:topics>
</item>
<item rdf:about="http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/">
    <title>What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability.</title>
    <dc:date>2015-11-09T12:31:56+00:00</dc:date>
    <link>http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/</link>
    <dc:creator>jm</dc:creator><description><![CDATA[The ever-shitty Java serialization creates a security hole]]></description>
<dc:subject>java serialization security exploits jenkins</dc:subject>
<dc:source>https://pinboard.in/</dc:source>
<dc:identifier>https://pinboard.in/u:jm/b:c0dc116c6113/</dc:identifier>
<taxo:topics><rdf:Bag>	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:java"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:serialization"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:security"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:exploits"/>
	<rdf:li rdf:resource="https://pinboard.in/u:jm/t:jenkins"/>
</rdf:Bag></taxo:topics>
</item>
</rdf:RDF>