Cooperative vs preemtive scheduling of virtual theads

Ron Pressler ron.pressler at oracle.com
Thu Jun 11 13:31:26 UTC 2020


1. 99% of applications probably won’t be relying on single-core multitasking as
an important performance technique (because it isn’t in general), so I don’t think
the concerns of 1% of applications should drive design decisions that could adversely
affect the other 99%.

2. I’m yet to see an example why scheduling inside class loading would introduce
any new issues, requiring new precautions, that aren’t already present today, even in 
the single-task case.

— Ron


On 11 June 2020 at 12:14:38, Andrey Lomakin (lomakin.andrey at gmail.com) wrote:

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