It's a performance bug, java.util.concurrent.TimeUnit is used when initializing the VM and because it use the abstract enum pattern, it requires to initialize a bunch of anonymous classes.

java -verbose:class -version
...
[Loaded java.util.concurrent.TimeUnit from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$1 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$2 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$3 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$4 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$5 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$6 from jrt:/java.base]
[Loaded java.util.concurrent.TimeUnit$7 from jrt:/java.base]

The code of TimeUnit should use a switches (like in toChronoUnit()) instead of relying on virtual dispatch.

Note that it's perhaps less 'object oriented' to use a switch instead of a virtual dispatch, but given that multiple enum values will be used as argument of a method call like Condition.await, currently the code creates megamorphic callsite inside await() when the enum value is converted to milisecond.