121–130 of 253 posts
Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
"to the trained eye you can already see that every single ai generated image is a picture of the same thing"
This problem is not going to go away so easily. Numerous core Java classes (like BufferedInputStream) use synchronized. I count 1600+ usages in java.base. The blocking issue means it's _much_ easier to accidentally run into this, rather than waving it away as an unlikely edge case. I personally ran into this Using the built in com.sun webserver, with a virtual thread executor. My VPS only has two CPUs which means the…
People always forget that things that only happen every few million times, can happen fairly frequently on a busy server. This has bitten me numerous times. The nature of a lot of these types of issues is that they are hard to detect and hard to reproduce. Virtual threads are nice for unblocking legacy code but they aren't without issues. There are better options for new code with less trade offs on the jvm as well.…
Earlier quoted context omitted.
Not really. I wish the trend of giant generic hero images on every blog post would go away, they almost never add any value. I think it was Medium that started the trend.
They do add value, they make clicks more likely.
"Making clicks more likely" is a terrible measure of genuine value.
There are lots of images which will make people click, even if once they see your page they click 'Back' a second later. Our metrics are broken if we continue to attribute that click as 'success'.
It is a known caveat that virtual threads do not work well with long running synchronization by pinning the thread. That unfortunately means that for many applications it may be premature to adopt them, but it is mature enough for broader evaluation by the libraries and frameworks. The Java team provided a status of their efforts recently [1]. https://www.youtube.com/watch?v=WoQJnnMIlFY&t=421s
Sorry, the first sentence is a mis-informing wording. The `synchronized` pins the thread only when from within of the `synchronized` the program calls a blocking operation that would normally unmount the virtual thread, like blockingQueue.take() or similar. (Which is not a sane coding practice). It's because the unmounting, as it's implemented today, does not work well with synchronized. It's better if people read JE…
It is a known caveat that virtual threads do not work well with long running synchronization by pinning the thread. That unfortunately means that for many applications it may be premature to adopt them, but it is mature enough for broader evaluation by the libraries and frameworks. The Java team provided a status of their efforts recently [1]. https://www.youtube.com/watch?v=WoQJnnMIlFY&t=421s
https://www.youtube.com/watch?v=WoQJnnMIlFY&t=260s To get the whole context, so virtual threads are unusable? What holds a monitor by default and is there a workaround? Found more: A virtual thread cannot be unmounted during blocking operations when it is pinned to its carrier. A virtual thread is pinned in the following situations: The virtual thread runs code inside a synchronized block or method The virtual thread…
That’s not true — blocking TCP IO is not implemented as blocking under the hood - that’s the whole point of virtual threads, so your conclusion is faulty.
The warning shots across the bow where heard with this statement from the devs: "Don't replace platform/native threads with virtual ones, replace tasks (without further explanation) instead"?! Combine that with the fact that they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems. Remember that NIO took from 1.5 to 1.7 to be usable/performant and that was native! Edit: F…
Ah yes, the argument from the 1990s. It would make sense to understand where the JVM and its compiler are these days before making incorrect statements about performance.
From your link:
> Blocking network TCP IO needs a sychronized block to work
This is utterly false.
Personally I am curious how these features like virtual threads are tested when developed.
The warning shots across the bow where heard with this statement from the devs: "Don't replace platform/native threads with virtual ones, replace tasks (without further explanation) instead"?! Combine that with the fact that they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems. Remember that NIO took from 1.5 to 1.7 to be usable/performant and that was native! Edit: F…