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.