creating virtual threads with attachment can hit hotspot check in the hot path

[franz1981]

I haven't investigated why, but this is pretty relevant (and not always reproducible), in the benchmark overall CPU usage - see

@AlanBateman

[AlanBateman]

The 3-arg unstarted method is a restricted method in the current prototype, so it has to test that the caller is in a module that has been granted the capability. Do you specify the preferredCarrier when you invoke this method?

[franz1981]

Do you specify the preferredCarrier when you invoke this method?

Netty-VirtualThread-Scheduler/core/src/main/java/io/netty/loom/EventLoopScheduler.java

Lines 116 to 117 in 24023af

	// we're not enforcing a preferred carrier on purpose, despite we could - to
	// prevent leaks to happen:

Nope, to prevent leaking the carrier eg

• the factory is wrapped in a lambda
• I should pass the carrier as arg which would be captured by the lambda
• if a user close the event loop but retain the factory it provide (using the lambda) the carrier won't be GCed

There is no other mechanism which check the call site just one time?

[AlanBateman]

There is no other mechanism which check the call site just one time?

The caller should only be only required in the current prototype when specifying non-null preferredCarrier. I've changed it so maybe you could pull the latest changes and re-test?

[franz1981]

Thanks @AlanBateman let me try it today 🙏

[franz1981]

I think this to be closed due to #68 which made the call not caller sensitive (thanks @AlanBateman !)