[ Content | Sidebar ]

New NVC version 1.5.2

July 28th, 2021

I’ve released a new version 1.5.2 of the VHDL compiler I’m working on. This is the second bug fix release on the 1.5 branch containing the following changes back-ported from the development branch:

  • Link libexecinfo on FreeBSD.
  • Implement textio READ procedure for BIT and TIME.
  • Fixed a crash when a long running procedure suspends in a loop.
  • Fix static linking with LLVM 12.0.
  • Fix crash when assigning to a signal declared in a package.
  • Fix incorrect recording of dependencies which caused a failure to load generated DLLs on Windows.
  • Fix file locking error when a library is located on NFS.
  • Optimise loading large library index from disk.
  • Fix a crash when using ‘VALUE with enumeration subtypes.
  • Fix a crash when a signal with more than 256 elements is declared in a package.

nvc-1.5.2.tar.gz
nvc-1.5.2.tar.gz.sig

This release is signed with GPG key fingerprint 0784 505A DB5D 7D86 D2BD E6DA BCDB 295F 7431 9F1A. Download both the .sig and .tar.gz files and verify with:

gpg --keyserver pgp.mit.edu --recv-keys BCDB295F74319F1A
gpg --verify nvc-1.5.2.tar.gz

There is now a public git mirror at https://git.nickg.me.uk/nvc.git if you prefer not to use GitHub.

Get Vaccinated Win An iPhone

July 25th, 2021

Throughout June and July the Shanghai local government has been trying a new tactic to convince people to take the coronavirus vaccine: bribes. At many vaccination centres you can be entered into a draw to win a phone or receive some other free gift. It’s clearly working as apparently 70% of adults have now been vaccinated. I’ve collected a few examples below that I either saw myself or were shared around on WeChat.

I passed this one on the way to work. The text says “get the coronavirus vaccination here and receive five litres of cooking oil”.

This district is clearly lacking imagination: the sign says “take the vaccine and receive 300 RMB cash after the second injection”.

A sign at Shanghai International Tourism Resort. It says “take the vaccine inside the resort and receive a free entrance ticket”.

This one says if you take the vaccine here, you’ll be entered into a prize draw. The top prize is an iPhone 12 and the second one is a Macbook, although the seventh prize is just some eggs.

This lady won a phone at another location after getting her vaccination. There’s a maximum of one per day but if you don’t win anything you still get five litres of cooking oil.

I Made a Cup

July 17th, 2021

In the interests of team building or something I made a clay cup at some pottery workshop. The results were surprisingly good and said cup is quite usable for drinking water.

The raw materials shaped with my own hands into something resembling a cup.

The painting process. Note the expert colour mixing going on.

The finished article. Note that it has shrunk quite a lot in the baking process.

Big Funnel

June 29th, 2021

The bright shopping mall from a few posts ago has an open courtyard in the centre with a large funnel-like object reaching up to the roof. Well I recently discovered you can go right to the top of it. And so here, for the first time ever, we bring you two exclusive views of said funnel.

If you’re wondering what’s inside the funnel, don’t bother: it’s just an elevator and doesn’t make for a good photo. It might also serve a secondary purpose for collecting rainwater.

Sandwich Recommendation

June 20th, 2021

After several years living abroad with all sorts of strange foreign food, I decided recently that I’d really rather just eat sandwiches for lunch. And finally I’ve found a bakery chain in Shanghai that sells sandwiches worthy of the name (hint: it’s not Family Mart).

The shop in question

It’s called Paris Baguette. But actually they’re not French at all but Korean. Whatever, their sandwiches are excellent, and also the egg tarts.

Exhibit A: three delicious ham rolls

Exhibit B: a delicious tuna sandwich

Taking Up Plane Spotting

May 29th, 2021

I unexpectedly had to suddenly move apartments last month. The new one is quite close to Hongqiao airport, which is Shanghai’s original and older airport. Thankfully not directly under the flight path, but parallel to it.

Taking off…

Much fun to be had cross-referencing with Flightradar24. Makes me wish I had a lens with a longer zoom.

Local shopping mall causing massive light pollution

The Dust Storm Cometh

March 30th, 2021

From the office it doesn’t look so bad…

Say what you like about UK weather, but I’ve never seen “sand, hazardous” before

Filed in musings - Comments closed

Final Fantasy VII

March 8th, 2021

The last few months I’ve been playing through the PC version of Final Fantasy VII. I first played this on the original PlayStation way back around year 9 in secondary school and it was the first time I’d played any kind of Japanese RPG.

Emerald Weapon


One of my friends was obsessed with the game and the lore around it. He had the golden Chocobo, all the materia and summons, and defeated both the Emerald and Ruby Weapon “superbosses”. I think I just played the main story through to the end and didn’t bother much with the optional content.

Press [OK] to slap…


I love the pre-rendered backgrounds, reminiscent of PC point-and-click adventure games of the same era. However they look a bit pixelated when scaled up on a large monitor (apparently they lost the original 3D scenes). The character models look great on a modern system though.

A regular battle


The story is great too and has tons of memorable characters (albeit mostly the antagonists). There’s a lot more depth to the story than I realised as a teenager. Perhaps my understanding at that time was hampered by the dodgy English translation, but it has a certain charm. I also much prefer the “science-plus-magic” setting to the common fantasy one, it’s almost a bit cyberpunk.

Finally got to level 99


What’s not great? Well it’s kinda easy: once you’ve figured out some tricks with the materia system the main story doesn’t have much challenge. I wish there was a configurable difficulty level (I heard the PC version has a mod to do this but haven’t tried). And the occasional mini-games, especially the snowboarding one, are annoying and haven’t aged well.

Filed in musings - Comments closed

Generating perf maps with OpenJDK 17

February 28th, 2021

Linux perf is a fantastically useful tool for all sorts of profiling tasks. It’s a statistical profiler that works by capturing the program counter value when a particular performance event occurs. This event is typically generated by a timer (e.g. 1kHz) but can be any event supported by your processor’s PMU (e.g. cache miss, branch mispredict, etc.). Try perf list to see the events available on your system.

A table of raw program counter addresses isn’t particularly useful to humans so perf needs to associate each address with the symbol (function) that contains it. For ahead-of-time compiled programs and shared libraries perf can look this up in the ELF symbol table on disk, but for JIT-compiled languages like Java this information isn’t available as the code is generated on-the-fly in memory.

Let’s look at what perf top reports while running a CPU-intensive Java program:

Samples: 136K of event 'cycles', 4000 Hz, Event count (approx.): 57070116973 lost: 0/0 drop: 0/0
Overhead  Shared Object                       Symbol
  16.33%  [JIT] tid 41266                     [.] 0x00007fd733e40ec0
  16.15%  [JIT] tid 41266                     [.] 0x00007fd733e40e3b
  16.14%  [JIT] tid 41266                     [.] 0x00007fd733e40df1
  16.14%  [JIT] tid 41266                     [.] 0x00007fd733e40e81
   2.80%  [JIT] tid 41266                     [.] 0x00007fd733e40df5
   2.62%  [JIT] tid 41266                     [.] 0x00007fd733e40e41
   2.45%  [JIT] tid 41266                     [.] 0x00007fd733e40ec4
   2.43%  [JIT] tid 41266                     [.] 0x00007fd733e40e87

Perf marks these locations as [JIT] because the addresses are in part of the process’s address map not backed by a file. Because the addresses are all very similar we might guess they’re in the same method, but perf has no way to group them and shows each unique address separately. Apart from that it’s not very helpful for figuring out which method is consuming all the cycles.

As an aside, it’s worth briefly comparing perf’s approach, which samples the exact hardware instruction being executed when a PMU event occurs, with a traditional Java profiler like VisualVM which samples at the JVM level (i.e. bytecodes). A JVM profiler needs to interrupt the thread, then record the current method, bytecode index, and stack trace, and finally resume the thread. Obviously this has larger overhead but there is a deeper problem: JIT-ed code cannot be interrupted at arbitrary points because the runtime may not be able to accurately reconstruct the VM state at that point. For example one cannot inspect the VM state halfway through executing a bytecode. So at the very least the JIT-ed code needs to continue executing to the end of the current bytecode. But requiring the VM to be in a consistent state at the end of each bytecode places too many restrictions on an optimising JIT. Therefore the optimised code can typically only be interrupted at special “safepoints” inserted by the JIT – in Hotspot this is at method return and loop back-edges. That means that a JVM profiler can only see the thread stopped at one of these safepoints which may deviate from the actual hot parts of the code, sometimes wildly. This problem is known as safepoint bias.

So a hardware profiler can give us better accuracy, but how to translate the JIT-ed code addresses to Java method names? Currently there are at least two tools to do this, both of which are implemented as JVMTI plugins that load into a JVM process and then dump some metadata for perf to use.

The first is the “jitdump” plugin that is part of the Linux perf tree. After being loaded into a JVM, the plugin writes out all the machine code and metadata for each method that is JIT compiled. Later this file can be combined with recorded profile data using perf inject --jit to produce an annotated data file with the correct symbol names, as well as a separate ELF shared object for each method allowing perf to display the assembly code. I use this often at work when I need to do some detailed JIT profiling, but the offline annotation step is cumbersome and the data files can be 100s of MB for large programs. The plugin itself is complex and historically buggy. I’ve fixed several of those issues myself but wouldn’t be surprised if there are more lurking. This tool is mostly overkill for typical Java developers.

The second tool that I’m aware of is perf-map-agent. This generates a perf “map” file which is a simple text file listing start address, length, and symbol name for each JIT compiled method. Perf will load this file automatically if it finds one in /tmp. As the map file doesn’t contain the actual instructions it’s much smaller than the jitdump file, and doesn’t require an extra step to annotate the profile data so it can be used for live profiling (i.e. perf top). The downsides are that profile data is aggregated by method so you can’t drill down to individual machine instructions, and the map can become stale with a long-running VM as methods can be unloaded or recompiled. You also need to compile the plugin yourself as it’s not packaged in any distro and many people would rightly be wary of loading untrusted third-party code which has full access to the VM. So it would be much more convenient if the VM could just write this map file itself.

OpenJDK 17, which should be released early next month, has a minor new feature contributed by yours truly to do just this: either send the diagnostic command Compiler.perfmap to a running VM with jcmd, or run java with -XX:+DumpPerfMapAtExit, and the VM will write a perf map file that can be used to symbolise JIT-ed code.

$ jps
40885 Jps
40846 PiCalculator
$ jcmd 40846 Compiler.perfmap
40846:
Command executed successfully
$ head /tmp/perf-40846.map 
0x00007ff6dbe401a0 0x0000000000000238 void java.util.Arrays.fill(int[], int)
0x00007ff6dbe406a0 0x0000000000000338 void PiSpigout.calc()
0x00007ff6dbe40cc0 0x0000000000000468 void PiSpigout.calc()
0x00007ff6dbe41520 0x0000000000000138 int PiSpigout.invalidDigitsControl(int, int)
0x00007ff6d49091a0 0x0000000000000110 void java.lang.Object.<init>()
0x00007ff6d4909560 0x0000000000000350 int java.lang.String.hashCode()
0x00007ff6d4909b20 0x0000000000000130 byte java.lang.String.coder()
0x00007ff6d4909ea0 0x0000000000000170 boolean java.lang.String.isLatin1()

Here we can see for example that the String.hashCode() method starts at address 0x00007ff6d4909560 and is 0x350 bytes long. Let’s run perf top again:

Samples: 206K of event 'cycles', 4000 Hz, Event count (approx.): 94449755711 lost: 0/0 drop: 0/0
Overhead  Shared Object                         Symbol
  78.78%  [JIT] tid 40846                       [.] void PiSpigout.calc()
   0.56%  libicuuc.so.67.1                      [.] icu_67::RuleBasedBreakIterator::handleNext
   0.34%  ld-2.31.so                            [.] do_lookup_x
   0.30%  libglib-2.0.so.0.6600.3               [.] g_source_ref
   0.24%  libglib-2.0.so.0.6600.3               [.] g_hash_table_lookup
   0.24%  libc-2.31.so                          [.] __memmove_avx_unaligned_erms
   0.20%  libicuuc.so.67.1                      [.] umtx_lock_67

This is much better: now we can see that 79% of system-wide cycles are spent in one Java method PiSpigout.calc().

Alternatively we can do offline profiling with perf record:

$ perf record java -XX:+UnlockDiagnosticVMOptions -XX:+DumpPerfMapAtExit PiCalculator 50
3.1415926535897932384626433832795028841971693993750
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.030 MB perf.data (230 samples) ]
$ perf report
Samples: 340  of event 'cycles', Event count (approx.): 71930116
Overhead  Command          Shared Object       Symbol
  11.83%  java             [JIT] tid 44300     [.] Interpreter
   4.19%  java             [JIT] tid 44300     [.] flush_icache_stub
   3.87%  java             [kernel.kallsyms]   [k] mem_cgroup_from_task
...

Here the program didn’t run long enough for any method to be JIT compiled and we see most of the cycles are spent in the interpreter. (By the way, the interpreter still looks like JIT-ed code to perf because its machine code is generated dynamically by Hotspot at startup.)

I’d be interested to hear from anyone who tries this new feature and finds it useful, or otherwise!