I get a crash here:

Current thread (0x00007fc21c025820): JavaThread "Unknown thread" [_thread_in_vm, id=8963, stack(0x000070000c4e2000,0x000070000c5e2000)]

Stack: [0x000070000c4e2000,0x000070000c5e2000], sp=0x000070000c5e1d90, free space=1023k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.dylib+0x944174] AdaptiveWeightedAverage::compute_adaptive_average(float, float)+0x7c
V [libjvm.dylib+0x9441b8] AdaptiveWeightedAverage::sample(float)+0x32
V [libjvm.dylib+0x956bf1] ThreadLocalAllocBuffer::initialize()+0x8f
V [libjvm.dylib+0x6dcaf3] attach_current_thread(JavaVM_*, void**, void*, bool)+0x13d
V [libjvm.dylib+0x6dc995] jni_AttachCurrentThread+0x28
V [libjvm.dylib+0x6dc8ae] jni_DestroyJavaVM+0x48
C [libjli.dylib+0x5200] JavaMain+0xc20
C [libjli.dylib+0x7679] ThreadJavaMain+0x9
C [libsystem_pthread.dylib+0x6109] _pthread_start+0x94
C [libsystem_pthread.dylib+0x1b8b] thread_start+0xf


siginfo: si_signo: 8 (SIGFPE), si_code: 1 (FPE_FLTDIV), si_addr: 0x0000000102544174

on macOS, x86_64, if I enable floating point signals for div by 0, using:

#include <xmmintrin.h>

  _MM_SET_EXCEPTION_MASK(_MM_GET_EXCEPTION_MASK() & ~_MM_MASK_DIV_ZERO);

but only with a very specific combination of Xcode version and built inside Xcode, the normal jdk built using make does not reproduce. Any timing changes, like using a printf() affects the behavior and can make it go away.

This looks like a bug in llvm compiler or macOS to me.

The code in question is in gcUtil.hpp:

  static inline float exp_avg(float avg, float sample,
                               unsigned int weight) {
    assert(weight <= 100, "weight must be a percent");
    return (100.0F - weight) * avg / 100.0F + weight * sample / 100.0F;
  }

and no division by zero is even possible here, still we get the crash and the signal SIGFPE, FPE_FLTDIV

A workaround, which also makes the code, in my opinion, more readable and probably numerically more stable is to rewrite the code as:

  static inline float exp_avg(float avg, float sample,
                               unsigned int weight) {
    assert(weight <= 100, "weight must be a percent");
    return ((100.0F - weight) * avg + weight * sample) / 100.0F;
  }

This is a nuisance issue more than anything, however, if the GC team would like to I can fix it.

With this fix anyone can turn on floating point signals and potentially not get tripped - it's a tiny, but non zero chance they would.