#15774 shows that few hot paths in netty (e.g. ByteBuf::getLong/indexOf) are severely affected in case the UNALIGNED information is not available.
Some of these methods are critical to HTTP 1.1 performance (e.g. ByteBuf::indexOf).
This can happen in few JVM implementations or due to security reasons, etc etc
I would be nice to leverage the newly introduced VarHandle stub in Netty 4.2 if such information is not available, but that means that we don't have to consider UNALIGNED = false and unavailable UNALIGNED, the same: they should be treated differently.
Here's why:

1. UNALIGNED = false but Unsafe available: ByteBuf::getLong performs 8 Unsafe::getByte
2. UNALIGNED not available but Unsafe available: ByteBuf::getLong should performs 1 VarHandle (byteArray or byteBuffer views)'s get which:

• could be backed by 8 Unsafe::getByte if hotspot knows that the OS doesn't allow unaligned accesses
• could be backed by 1 Unsafe::getLong, otherwise

If we treat UNALIGNED unaivalable and false to be the same we miss the chance for hotspot to do "the right thing".