| Location | London |
@pressron
- 396 Followers
- 196 Following
- 62 Posts
@ahelwer I think I can articulate "simplicity" more precisely as the number and regularity of inference (deduction) rules necessary for the intended usage (execution for programming, analysis for TLA+). This highly depends on the (abstract) syntax. The length of the parser is more a function of the concrete syntax (and also not a big concern for a language focused on analysis rather than execution).
What might have happened is that the university was using new updates to very old versions of Java (8?) in its *internal IT systems*. That has never been free since the dawn of Java almost 30 years ago.
Anyway, what I wrote above is true. Oracle Java is free, with updates, for <3-year-old versions for any purpose, and older versions are free, with updates and technical support, for academic use.
@witewulf
FYI, Oracle Java is free for personal and commercial use as of JDK 17, period (as the website states: https://www.oracle.com/java/technologies/downloads/)
For older versions that no longer receive free updates, academic institutions get free support: https://blogs.oracle.com/java/post/oracle-academy-java-se-technical-support
@chriswhocodes Sure, although a switch expression would make the code clearer, I think.
Further down the line we would like to add channels (which are like blocking queues but with additional operations, such as explicit closing), and possibly generators, like in Python, that make it easy to write iterators.
In the medium term we’d like to incorporate io_uring, where available, to offer scaling for filesystem operations in addition to networking operations. We may also offer custom schedulers: Virtual threads are currently scheduled by a scheduler that’s a good fit for general-purpose servers, but more exotic uses may require other scheduling algorithms, so we’d like to support pluggable custom schedulers.
The workaround today is to identify those instances with observation tools in the JDK and to replace them with java.util.concurrent locks, which don’t suffer from pinning. We’re working to stop synchronized from pinning so that this work won’t be needed.
Additionally, we’re working on improving the efficiency of the scheduling of IO operations by virtual threads, improving their performance further.
What may be coming down the line? In the short term, we’re working on fixing what may be the biggest hurdle to a transparent adoption of virtual threads: pinning due to synchronized. Currently, inside synchronized blocks or methods, IO operations that would normally release the underlying OS thread block it instead. That's "pinning", and if it happens frequently and for long durations it can harm the scalability of virtual threads.
ScopedValue is a superior alternative to ThreadLocal when it comes to its most common use: as a mechanism to associate context with a scope of code without passing method arguments. For that use case, ScopedValues are more efficient than ThreadLocals, and less prone to incorrect usage that can lead to bugs. Although they interact in an interesting way with structured concurrency, scoped value are completely orthogonal to virtual threads.