Oracle’s OpenJDK is the only one that is built without supporting Shenandoah GC.
1,569 karma · joined November 5, 2013
https://speakerdeck.com/alblue/a-brief-history-of-unicode-45...
https://speakerdeck.com/alblue/understanding-cpu-microarchit...
The presentation was recorded and is on YouTube
This talk, given for the JChampionsConf in 2022, presents the microarchitecture of modern CPUs, showing how misaligned data can cause cache line false sharing, how branch prediction works and when it fails, how to read CPU specific performance monitoring counters and use that in conjunction with tools like perf and toplev to discover where bottlenecks in CPU heavy code live. We’ll use these facts to revisit performance advice on general code patterns and the things to look out for in executing systems.
The talk will be language agnostic, although it will be based on the Linux/x86_64 architecture. The presentation was recorded at the JChampionsConf meeting in January 2022, and a recording is available here: https://youtu.be/Pa_l3aHCoGc
Actually, the current vaccines still seem to be doing a pretty good job, even with the latest variant (and there are always more variants). While none of the vaccines have ever claimed to prevent you catching covid 100%, they have prevented 90%+ against catching the disease and have reduced the severity of the disease in those who have caught it. It’s why emergency rooms around the world are largely filled with unvaccinated people, and most of the ones in hospital who go on to die are the unvaccinated.
Think of it as giving your body a natural head start to fighting off the infection. In the end, it’s your immune system that saves you, not the vaccine — but the vaccine stacks the deck significantly in your favour for a full recovery.
Of course the virus is mutating, and it’s possible that the next one will escape the mRNA vaccines that currently exist due to the different shape of the protein; but we have essentially developed a whole new science of how to create vaccines quickly from a known protein spike, so it will be a matter of months from discovery of an escaping strain to a protective vaccine for it.
In any case, the approaches used here are valid for more than just covid; an exciting HIV vaccine is undergoing trials at the moment And there’s potential to treat other kinds of viral diseases in this way.
https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
While Rust may have less issues than other languages in this regard, it doesn’t change the fact that destruction of a “thing” can result in a transitive set of “other things” being destroyed as well, and depending on the state of the program, this set could have a pretty high bound.
Even in a “predictable” language like Rust, a data entry containing a map like structure is going to have a different destruction time if the map is empty vs if it is full.
The other aspect of “predictable” delays in a program completely ignores the runtime issues that can happen at the OS layer, such as swapping/page cache invalidations/migrations between cores of numa regions etc. so it is rarely the case that any program in any language is going to have predictable behaviour. Even trivial things, like the number/size of environment variables user at program startup can have a performance delta.
Anyway, the point is that when programmers talk about “predictable” behaviour in a program, what they generally mean is “invisible performance problems” and so it gets swept under the carpet.
That’s not to say that GC doesn’t introduce variance into measurements, but it is not the only thing that causes variance and many of the good GCs are capable of using multiple cores and can avoid interrupting the program runtime without significant overhead, although obviously tracing collectors will increase pressure on a memory system in a way that explicit/automatic memory management does not.
Swift came out of the iOS side of the company, and was sponsored to make writing iOS apps easier. It was therefore constrained to fit into a particular shape; in particular, Objective-C compatibility was a must have. Many of the frameworks and libraries on iOS/macOS are implemented in Objective-C including “std” libraries like Foundation.
When building Swift for Linux/Windows, there isn’t an Objective-C ecosystem, and rather than introduce one, instead the language just doesn’t have support for that. As a result, the “std” libraries are a complete rewrite of the libraries available on macOS. Even being able to include Posix basics used a different library name; Darwin vs GlibC. [There was a long battle to try and get a meta import of LibC which would import the right one on different platforms.]
So there are really two dialects of the language: Apple Swift and Linux/Windows Swift. They share the same overall feel but is like the difference between Diesel and Petrol/Gas. Same overall outcome, different completely under the hood.
Two other reasons exist; firstly, the internal builds are a fork of the open source project, so when a new feature lands on an iOS device, code and libraries are written to support that (eg SwiftUI) and nothing related to that fork lands until after Apple have announced it. What that means is you get giant blobs of diffs on an annual basis; in some cases, reverting bugs that have been fixed already in the open source world (because the internal version was forked six months previously).
The other reason is that Swift depends on a forked version of llvm/clang, to the extent where you have to install those to be able to compile Swift programs. Many upstream distributions already ship their own clang, which is essentially incompatible with Swift, but they want to follow their philosophy of only one version of a library (and don’t want to replace their own version with a Swift specific one).
So, Swift on iOS is a primary platform, and if you are writing iOS apps is the standard way. Every other platform is a second class citizen and software project management at Apple is not well suited to an open source workflow; since the iOS team are calling the shots on swift (and paying for most of it, to be fair) then the language evolves for their benefit primarily and then others as a side effect.
https://docs.aws.amazon.com/general/latest/gr/ao.html
As a result, even if you weren’t using that region but you were using the API you were hosed for 6+ hours, And the status page never acknowledged that it was out of action.
We had the following Terraform in our production pipeline:
data “aws_organizations_organization” “current” {}
As a result, all of our deployments to our EU regions were borked. Of course, we couldn’t raise a support case because the support system was also down, and despite escalating to our TAM weren’t able to get the status page to reflect reality.
My concern is that the Organizations API specifically will be brushed under the carpet and we will still have a single point of failure in a region which we never intend to use.
Plus, they actually serve the Raspberry Pi foundation website and the raspian images /from Raspberry Pis/ so they know what they are doing.
While you can do this by embedding an AWS IAM secret as a GitHub secret, it may lead to the secret escaping. Instead, you can configure AWS to trust GitHub actions, And set up passwordless trust between the two.
I wrote up how to do it here at StackOverflow if you’re interested:
My management chain veto’d the transfer, which was the day I decided to quit. I started looking for opportunities outside that company, and within six months had moved on to a job with significantly more responsibility than my original or other routes within the FAANG.
Companies that prevent internal transfer turn them into external transfers.
The problem was that it has serious scaling issues, and when you move mail to it (and remember it has to do the synchronisation step when you return) it can bog down both the server And the client. It was far less efficient than, say, pop and imap.
IBM took a bet that they could make Notes scale to the entire org in the mid-to-late ‘90s, and it took many years to get there and much pain along the way.
Any large and crufty system can start to have problems as they grow older but “fixing notes” wasn't a programming issue but a design one.
In todays terminology, it would be the equivalent of a replicated/distributed MongoDB with the designated “master” on the server, with a cached full copy of that database on your laptop (which isn't permanently connected), while allowing writes in both partitions (ie sacrificing consistency for availability) and then hoping when you connect it back up again that it can figure out the bidirectional sync and resolve any conflicts that occur.
And then on top of that build a mail client which stores one mail message per row (including all attachments) along with status bits (read, important, replied etc) and hope to heck it all works.
Lotus Notes “synchronization” was the step you did after docking your thinkpad just before going to get your first coffee of the day, because hopefully the latency would be hidden by the brewing time.
Id be very surprised if the other large enterprises that I have worked at downs doing exactly the same thing. Too much legal risk, for practically no benefit.
The script uses its name to look for a corresponding dockerfile/container (which it auto builds if needed) and then mounts the file system inside to allow you to run it on one or mode files locally.
See eg
https://github.com/alblue/scripts/blob/main/ctags https://github.com/alblue/scripts/blob/main/ctags-Dockerfile