Jobs API on its way

[Etienne Pierre-doray]

TL;DR: Jobs API will be exposed publicly in base/task/post_job.h in this CL

The Jobs API is a power user API, mostly intended for v8, to be able to schedule a single base::RepeatingCallback and request that ThreadPool workers invoke it concurrently. This avoids degenerate cases which occur when many components post “num cores” tasks and the scheduler lacks context. The API also supports yield-semantics so user-visible job can use all cores but get out of the way when a user-blocking job comes in.

... and it's ready!

However, I'm not sure how to go about exposing the API in v8::Platform. 

Similar to v8::TaskRunner, the straightforward solution is to replicate classes (JobHandle, JobDelegate) with virtual interfaces and further extend v8::Platform to expose PostJob(). This adds overhead however, especially for JobDelegate::ShouldYield() which should be called very often. 

I'd like to get input from v8 folks, and see if there are other solutions I haven't considered.

[Clemens Backes]

Hi Etienne,

I just want to express my excitement about this new API! It looks like exactly what we need for WebAssembly compilation (and tier-up). We can probably remove quite a few hacks when switching to the Jobs API.

So thanks a lot for implementing this!

I am not an API or platform expert, so I cannot help with the original question :/

Cheers,

Clemens

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CALoDvsboGKxjaYWfjcaEnu8U8XbRK_zi8auaTQ3y74-8L155%3Dg%40mail.gmail.com.

--

Clemens Backes

(né Hammacher)

Software Engineer

clem...@google.com

Google Germany GmbH

Erika-Mann-Straße 33

80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Ulan Degenbaev]

Hi Etienne,

Thanks for working on this! I am looking forward to using the new API.

At least for concurrent marking use case, the overhead of the virtual call in ShouldYield will be small because we will call it after marking a group of objects (~O(1ms)).

The reason is that for yielding we need to do additional work, like flushing the thread-local segments of the marking worklist. That work has to be amortized.

So the straightforward solution with virtual functions is okay for GC and I don't see an alternative to that.

There is another V8 specific caveat: we need to accommodate for V8 embedders that do not implement the new Jobs API.

So either we need a simple default implementation for the new API on top of the existing runner in v8::Platform.

Or each place in V8 that wants to use the new Job API has to check if the platform supports it and correctly fallback to the old task API.

Cheers,

Ulan.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAGO%3DqhD0cxC94G-3ZQAsGTME_NqNSi1NuUUUgxC9b19jDsmtyg%40mail.gmail.com.

[Gabriel Charette]

Another question is who should be in charge of exposing this on the v8 side? Etienne's mandate was mostly to expose such an API in Chromium, does anyone on v8 team want to now own the integration in v8::Platform and migration of v8 usage?

@etiennep : let's open a bug to track the integration in v8 and figure out who would own it.

Re. Default impl for v8 embedders, the default impl can probably just post std::min(num_cores-1, max_concurrency) copy of the task and always return false for ShouldYield()?

You received this message because you are subscribed to the Google Groups "scheduler-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheduler-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CABNJt2Lmsqin56T8Y6X1dTWvhaAiti8f-zwxAU6yV8YkowVD2Q%40mail.gmail.com.

[Michael Lippautz]

We could make use of this in Oilpan first which has access to //base and port over concurrent sweeping to use the jobs API. That port be owned by Oilpan folks.

That would allow us to test it first before threading it through all the necessary layers for V8.

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAJTZ7L%2BgO5gEdeZwpHdtyxgSDm_6ayv4RSm-MGn-%3DdxzQuxVbA%40mail.gmail.com.

[Gabriel Charette]

That sounds great. I think +Etienne Pierre-doray is the right person to drive the first field use case as he'll be in the best position to adapt the API (which is still in experimental::) if it doesn't end up easy to use.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/scheduler-dev/CAH%2BmL5BOWCBPwF%2BNQZMKEmrHL0oMiZwbOtt1q4Z%3D6NzF7m9dbg%40mail.gmail.com.