Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Add virtual thread support #1299

Closed
wants to merge 1 commit into from
Closed

Conversation

He-Pin
Copy link
Member

@He-Pin He-Pin commented Apr 27, 2024

Motivation:
Add virtual thread support

Modification:

  1. Run Actor on top of ThreadPerTaskExecutor.

Result:
Virtual thread support was added.

Note:
As Mailbox extends on ForkJoinTask and when we run on ThreadPerTaskExecutor, it's pointless.

@pjfanning
Copy link
Contributor

pjfanning commented Apr 28, 2024

This is probably useful but I would appreciate if we don't merge it until after 1.1.0-M1 is released. I think there are some changes that we need in the implementation and we have to work out how to test it.

I don't think this dispatcher should be the default, even if you use JDK 21+. Users should only be able to opt in to using it.

Dispatchers are pluggable so users can create their own dispatcher for this while they are waiting for us to release one.

@He-Pin
Copy link
Member Author

He-Pin commented Apr 29, 2024

Yes, I would like to make it in 1.1.0 M2 or M3 , Need more time to polish it.

@He-Pin
Copy link
Member Author

He-Pin commented Jul 13, 2024

@pjfanning @alexandru @Roiocam @alexandru What do you think about the current way to support virtual thread in pekko?
I was want to replace the virtual thread's shceudler, but that need a methodHandler method in Java 9+.

var builder = ofVirtualMethod.invoke()
val nameMethod = lookup.findVirtual(ofVirtualClass, "name",
MethodType.methodType(ofVirtualClass, classOf[String], classOf[Long]))
// TODO support replace scheduler when we drop Java 8 support
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

      if (executor != null) {
        val clazz = builder.getClass
        val privateLookup = MethodHandles.privateLookupIn(
          clazz,
          lookup
        )
        val schedulerFieldSetter = privateLookup
          .findSetter(clazz, "scheduler", classOf[Executor])
        schedulerFieldSetter.invoke(builder, executor)
      }


@InternalApi
private[dispatch] object VirtualThreadSupport {
private val lookup = MethodHandles.lookup
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you use public lookup?

# then the executor configured in "fallback" will be used.
virtual-thread-executor {
#Please set the the underlying pool with system properties below:
#jdk.virtualThreadScheduler.parallelism
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can these be supported as configs as opposed to relying on system properties?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but that will need to create a dedicated fork-join pool with a new factory for the CarrierThread( but which lives in java.internal.misc`... we have that internal but not sure if that's a good idea for an opensource project.

@pjfanning
Copy link
Contributor

Could you add a basic unit test?

@pjfanning
Copy link
Contributor

@He-Pin would you have time to add a test that runs when we build with java 21+? And there is my comment about using MethodHandles publicLookup instead of lookup. Generally, I support adding this. I'm hoping to try to get the final changes merged so that we can press ahead with Pekko 1.1.0 or 1.1.0-M2 release.

@He-Pin
Copy link
Member Author

He-Pin commented Jul 25, 2024

I'm a little busy at work but I would like to address this this weekend night, at day I need go to the apache coc in HangZhou.

@pjfanning
Copy link
Contributor

#1436 was merged

@pjfanning pjfanning closed this Aug 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants