On Fri, 13 Dec 2024 14:30:37 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> There has been a latent problem in `GDIHashtable` since time immemorial, but > due to sheer luck it has not caused any issues for us. However, I managed to > provoke it when I was doing some build changes. > > This is the problem: > In `GDIHashtable`, there is a static field > `GDIHashtable::BatchDestructionManager manager`, which is initialized in > `GDIHashtable.cpp`. > > In `AwtPen`, there is a static field `GDIHashtable cache`, which is > initialized in `awt_Pen.cpp`. > > The `GDIHashtable` constructor calls `manager.add(this)`. > > For this to work, the manager must have been initialized prior to the AwtPen. > However, the order of which static initializers are run between different > compilation units are not well-defined, and we've just been lucky so far that > it works. > > This problem is known as the "Static Initialization Order Fiasco", see e.g. > https://en.cppreference.com/w/cpp/language/siof > > I have solved this by encapsulating the static manager instance in a method, > which guarantees that it has been initialized before use. This seemed to me > to be the cleanest solution. Any reviewers on this? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22736#issuecomment-2548055286
