PatchWarmup

Warms the patch engine on a background thread at init, so the first script calling Patches doesn't pay the self-attach and ByteBuddy's class loading on a tick thread — seconds of it where no flag permits a direct self-attach and ByteBuddy falls back to spawning a second JVM to attach on its behalf.

Unconditional and not configurable: there is nothing to opt out of. No class in the JVM is touched — see Patch.warm — so all that is left is work the first Patches call would have done anyway, moved off a tick thread that cannot interrupt it, plus on a server that never calls Patches the JDK's dynamic-agent warning block. A flag defaulting to off would just mean nobody gets this.

Its own object rather than a method on Instrumentations, for the load-order reason that one documents: this references Patch.

Functions

Link copied to clipboard
fun start()