Cooperative vs preemtive scheduling of virtual theads

Andrey Lomakin lomakin.andrey at gmail.com
Thu Jun 11 11:14:22 UTC 2020


Hi Andrew,

> One day we surely want the Java runtime, class loading included, to be
> written in Java. Therefore, we should be ready for all blocking events
> in the VM one day to be scheduling points. No?  It's not a good thing
> that class loading blocks a carrier thread, more an artifact of the
> current implementation.


Sure that is completely above my pay grade, but I dare to add my 5 cents.
Persanally I think that side effects which are caused by the fact that
application is running inside of managed language should be as cheap as
possible. The class loading happens once in a while of  whole life time of
Java application, so in 99.99% of application life span users will not
exhibit side effects of fact that class loader blocked the carrier thread,
but if it would be needed to put memory fences to avoid situations which
virtually never happens that will affect the 100% of application life span.
So probably would be more user friendly to make side effects as cheap as
possible (do not use blocking for example at all) than enforce
additional precautions at the places when they can be avoided ?

On Thu, Jun 11, 2020 at 1:34 PM Andrew Haley <aph at redhat.com> wrote:

> On 09/06/2020 11:41, Ron Pressler wrote:
>
> > However, if you can find an example where it, or some other platform
> > mechanism, does introduce new issues if it were made a scheduling
> > point, we will certainly consider promising it won't be.
>
> One day we surely want the Java runtime, class loading included, to be
> written in Java. Therefore, we should be ready for all blocking events
> in the VM one day to be scheduling points. No?  It's not a good thing
> that class loading blocks a carrier thread, more an artifact of the
> current implementation.
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>

-- 
Best regards,
Andrey Lomakin.


More information about the loom-dev mailing list