3 ms·

> How would I implement this logic in my own libraries? There's no need to if your code is in Java. We had to change low-level I/O in the JDK because it drops

by pron 4y ago

> How would I implement this logic in my own libraries? There's no need to if your code is in Java. We had to change low-level I/O in the JDK because it drops down to native. That's not to say every Java library is virtual-thread-friendly. For one, there's the issue of pinning (see the JEP) that might require small changes (right now the problem is most common in JDBC drivers, but they're already working on addressing it). The bigger issue, mostly in low-level frameworks, is implicit assumptions about a small number of shared threads, whereas virtual threads are plentiful and are never pooled, so they're never shared. An example of such an issue is in Netty, where they allocate very large native buffers and cache them in ThreadLocals, which assumes that the number of threads is low, and that they're reused by lots of tasks.

_benedict 4y ago
Conversely, some applications would like a leaky abstraction they have some control over. Some caching will likely remain beneficial to link to a carrier thread. As a member of the Cassandra community I’m super excited to get my hands on virtual threads come the next LTS (and Cassandra’s upgrade cycle), as it will permit us to solve many outstanding problems much more cheaply. I hope by then we’ll also have facilities for controlling the scheduling of virtual threads on carrier threads. I would rather not wait another LTS cycle to be able to make proper use of them.
- pron 4y ago
  LTS is a designation by our sales organisation for arbitrarily chosen versions so they can offer a support service for legacy codebases -- i.e. people willing to pay for the privilege of not getting new features [1]. Why anyone would wait for something intended for the sole purpose of not adding new features to get a new feature --and so enjoying the very worst of both worlds -- is beyond me. The development organisation has no consideration of support offerings. All releases are equal, and the assumption is that those who want new features obviously do not want LTS and vice-versa. Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. [1]: There are many legacy applications that aren't actively developed. They have no use for new features, and new features sometimes requires changing configurations -- a hassle they don't have the people to do. So LTS is a subscription service that allows them to get releases without new features so they can keep running legacy apps without much maintenance. It's a great service, but obviously the opposite of what actively maintained codebases want; for them we have the regular upgrade model.
  - Twisol 4y ago
    > Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. I, for one, appreciate the repeat. I usually have to go hunting for one of your much older Reddit comments when this topic comes up at work.
  - btbuilder 4y ago
    The good work to slim down and better compartmentalize the JDK has historically created enough backward incompatibility risks for me that I prefer staying on the same version longer than 6 months. If I want security updates for the version I’m on LTS is the best (only?) way.
    - pron 4y ago
      I think Java has never had better backward compatibility than now. The difficulties migrating to 9 were 1. due to 9 being the last major release ever, and 2. libraries that hacked JDK 8's internals and were not portable, so they broke in a big release. The overall upgrade costs now are also lower than ever before, and we know that because some companies do understand that using the current version is easier and cheaper than an old one. Having said that, if you want to stay on an old version for a long time, then yes, use one with LTS, but then you might as well upgrade very slowly (not every two years) because upgrades will be less pleasant.
      - btbuilder 4y ago
        I agree, Java compatibility is much better now. For Java 9 there were also runtime breaking changes like removal of javax classes and removal of javaFX. >6 months is not really a long time for enterprise software.
        pron 4y ago
        But Java has always had semi-annual feature releases, and there wasn't even LTS -- people had to upgrade to a new feature release ever six months. It's just that we dropped major releases altogether and then gave the feature releases new version numbers, and that confused many people (who might not have even been aware that some of the minor releases in the past were actually quite significant feature releases). In other words, people upgraded to new feature releases every six months in the Java 7 and 8 era, too; now with major releases gone it's even easier, so it doesn't make sense that projects that were fine with such upgrades in the past all of a sudden need the new LTS model when things are even easier than before.
fibersfan 4y ago
> An example of such an issue is in Netty, where they allocate very large native buffers and cache them in ThreadLocals, which assumes that the number of threads is low, and that they're reused by lots of tasks. Fixing Netty is very high yield. Every modern Java server application I'm aware of uses Netty. Quarkus, Vertx, Micronaut, Java-GRPC, ... Then Graal? Virtual threads in Graal with a Netty that isn't 60MB would be superb. What about just shimming Netty? Is that in Oracle's scope? There are already selectable backends for Netty. Why not have "virtualthread-graalcompatible" that uses your already fixed Java IO? It would reduce so much pain, and make Java competitive with golang for the first time ever.
- mike_hearn 4y ago
  GraalVM native images have recently gained support for virtual threads. So you can have AOT compiled fast starting binaries that use virtual threads, if you want (or very soon at least, I can't recall if it's out yet or not). The main gap vs Go would then be the speed of the AOT compile. But you normally develop on HotSpot anyway. Netty already works with Loom. There are people doing experiments with it where it shows some small performance gains even. They are incrementally improving it so it works better when Loomified, but it does work.
  - pjmlp 4y ago
    It is surely not out yet, latest stable GraalVM is still based on Java 17.
  - kaba0 4y ago
    Graal also has a “fast build” mode, likely way slower still than go’s compilation, but there is that. It is meant for development though, you will likely want an optimized build for prod. But yeah, one should probably just develop in the traditional way, and then test it out in native after a few iterations.
- nhoughto 4y ago
  Do you need Netty in a virtual thread world? Imo Netty made non blocking IO in Java tractable.. but virtual threads does it better and more broadly, so what role does netty play now? What other than thread efficiency does it bring that can’t be achieved more easily now?

by pron 4y ago

_benedict 4y ago

Conversely, some applications would like a leaky abstraction they have some control over. Some caching will likely remain beneficial to link to a carrier thread. As a member of the Cassandra community I’m super excited to get my hands on virtual threads come the next LTS (and Cassandra’s upgrade cycle), as it will permit us to solve many outstanding problems much more cheaply. I hope by then we’ll also have facilities for controlling the scheduling of virtual threads on carrier threads. I would rather not wait another LTS cycle to be able to make proper use of them.

pron 4y ago
LTS is a designation by our sales organisation for arbitrarily chosen versions so they can offer a support service for legacy codebases -- i.e. people willing to pay for the privilege of not getting new features [1]. Why anyone would wait for something intended for the sole purpose of not adding new features to get a new feature --and so enjoying the very worst of both worlds -- is beyond me. The development organisation has no consideration of support offerings. All releases are equal, and the assumption is that those who want new features obviously do not want LTS and vice-versa. Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. [1]: There are many legacy applications that aren't actively developed. They have no use for new features, and new features sometimes requires changing configurations -- a hassle they don't have the people to do. So LTS is a subscription service that allows them to get releases without new features so they can keep running legacy apps without much maintenance. It's a great service, but obviously the opposite of what actively maintained codebases want; for them we have the regular upgrade model.
- Twisol 4y ago
  > Anyway, the mention of the perennially misunderstood Java LTS is a pet peeve of mine, so I'm sorry if this comment was overly aggressive. I, for one, appreciate the repeat. I usually have to go hunting for one of your much older Reddit comments when this topic comes up at work.
- btbuilder 4y ago
  The good work to slim down and better compartmentalize the JDK has historically created enough backward incompatibility risks for me that I prefer staying on the same version longer than 6 months. If I want security updates for the version I’m on LTS is the best (only?) way.
  - pron 4y ago
    I think Java has never had better backward compatibility than now. The difficulties migrating to 9 were 1. due to 9 being the last major release ever, and 2. libraries that hacked JDK 8's internals and were not portable, so they broke in a big release. The overall upgrade costs now are also lower than ever before, and we know that because some companies do understand that using the current version is easier and cheaper than an old one. Having said that, if you want to stay on an old version for a long time, then yes, use one with LTS, but then you might as well upgrade very slowly (not every two years) because upgrades will be less pleasant.
    - btbuilder 4y ago
      I agree, Java compatibility is much better now. For Java 9 there were also runtime breaking changes like removal of javax classes and removal of javaFX. >6 months is not really a long time for enterprise software.
      - pron 4y ago
        But Java has always had semi-annual feature releases, and there wasn't even LTS -- people had to upgrade to a new feature release ever six months. It's just that we dropped major releases altogether and then gave the feature releases new version numbers, and that confused many people (who might not have even been aware that some of the minor releases in the past were actually quite significant feature releases). In other words, people upgraded to new feature releases every six months in the Java 7 and 8 era, too; now with major releases gone it's even easier, so it doesn't make sense that projects that were fine with such upgrades in the past all of a sudden need the new LTS model when things are even easier than before.

fibersfan 4y ago

> An example of such an issue is in Netty, where they allocate very large native buffers and cache them in ThreadLocals, which assumes that the number of threads is low, and that they're reused by lots of tasks. Fixing Netty is very high yield. Every modern Java server application I'm aware of uses Netty. Quarkus, Vertx, Micronaut, Java-GRPC, ... Then Graal? Virtual threads in Graal with a Netty that isn't 60MB would be superb. What about just shimming Netty? Is that in Oracle's scope? There are already selectable backends for Netty. Why not have "virtualthread-graalcompatible" that uses your already fixed Java IO? It would reduce so much pain, and make Java competitive with golang for the first time ever.

mike_hearn 4y ago
GraalVM native images have recently gained support for virtual threads. So you can have AOT compiled fast starting binaries that use virtual threads, if you want (or very soon at least, I can't recall if it's out yet or not). The main gap vs Go would then be the speed of the AOT compile. But you normally develop on HotSpot anyway. Netty already works with Loom. There are people doing experiments with it where it shows some small performance gains even. They are incrementally improving it so it works better when Loomified, but it does work.
- pjmlp 4y ago
  It is surely not out yet, latest stable GraalVM is still based on Java 17.
- kaba0 4y ago
  Graal also has a “fast build” mode, likely way slower still than go’s compilation, but there is that. It is meant for development though, you will likely want an optimized build for prod. But yeah, one should probably just develop in the traditional way, and then test it out in native after a few iterations.
nhoughto 4y ago
Do you need Netty in a virtual thread world? Imo Netty made non blocking IO in Java tractable.. but virtual threads does it better and more broadly, so what role does netty play now? What other than thread efficiency does it bring that can’t be achieved more easily now?