4 ms·

It's great to see even incremental performance fixes are still getting backported (eg: https://bugs.openjdk.java.net/browse/JDK-8229022 https://bugs.openjdk.jav

by zmmmmm 6y ago

It's great to see even incremental performance fixes are still getting backported (eg: https://bugs.openjdk.java.net/browse/JDK-8229022 https://bugs.openjdk.java.net/browse/JDK-8229022). I am curious how long that will be maintained as it must surely be quite a bit of effort.

MaxBarraclough 6y ago
The backporting work is being done by Oracle, right? I imagine there could be some risk-averse Java-powered companies out there willing to pay good money to keep their old JVMs patched, to avoid the risks of upgrading.
- zmmmmm 6y ago
  > some risk-averse Java-powered companies out there There millions of them. But if anything I would expect that risk aversion to translate into not back porting discretionary performance fixes. For example, the fix I linked to improves BufferedReader performance by swapping a thread-safe underlying class for a non-thread-safe version. That could introduce race conditions and other synchronization issues into its behavior. Thread safety was never specified in the API so that's fine for prospective versions, but having this land unexpectedly in a minor version update bundled with security patches .... is almost the opposite of what I would want.
  - MaxBarraclough 6y ago
    Well spotted. Surprised no-one even mentioned this in the comments there.
  - NovaX 6y ago
    It is a method-scoped variable that is operated on under the reader's lock. Therefore the additional locking by StringBuffer is unnecessary and there is no negative impact by switching to StringBuilder.
    - zmmmmm 6y ago
      You're right - it makes me feel a bit better. But the underlying point ... that I'm surprised this sort of thing is getting backported, I think is still the same.
- twic 6y ago
  I had a vague idea that Red Hat was in some sense now responsible for Java 8: https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/ https://developers.redhat.com/blog/2018/09/24/the-future-of-... But that particular bug was backported by someone at Oracle.
  - karianna 6y ago
    One of the Red Hat engineers (Andrew Haley) is the lead of jdk8u but that’s officially him as an individual as opposed to RH the company
- jillesvangurp 6y ago
  Amazon is also pretty active maintaining v8 with Amazon Coretto. Red Hat, Azul also provide certified builds to their customers.

by zmmmmm 6y ago

MaxBarraclough 6y ago

The backporting work is being done by Oracle, right? I imagine there could be some risk-averse Java-powered companies out there willing to pay good money to keep their old JVMs patched, to avoid the risks of upgrading.

zmmmmm 6y ago
> some risk-averse Java-powered companies out there There millions of them. But if anything I would expect that risk aversion to translate into not back porting discretionary performance fixes. For example, the fix I linked to improves BufferedReader performance by swapping a thread-safe underlying class for a non-thread-safe version. That could introduce race conditions and other synchronization issues into its behavior. Thread safety was never specified in the API so that's fine for prospective versions, but having this land unexpectedly in a minor version update bundled with security patches .... is almost the opposite of what I would want.
- MaxBarraclough 6y ago
  Well spotted. Surprised no-one even mentioned this in the comments there.
- NovaX 6y ago
  It is a method-scoped variable that is operated on under the reader's lock. Therefore the additional locking by StringBuffer is unnecessary and there is no negative impact by switching to StringBuilder.
  - zmmmmm 6y ago
    You're right - it makes me feel a bit better. But the underlying point ... that I'm surprised this sort of thing is getting backported, I think is still the same.
twic 6y ago
I had a vague idea that Red Hat was in some sense now responsible for Java 8: https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/ https://developers.redhat.com/blog/2018/09/24/the-future-of-... But that particular bug was backported by someone at Oracle.
- karianna 6y ago
  One of the Red Hat engineers (Andrew Haley) is the lead of jdk8u but that’s officially him as an individual as opposed to RH the company
jillesvangurp 6y ago
Amazon is also pretty active maintaining v8 with Amazon Coretto. Red Hat, Azul also provide certified builds to their customers.