> Can I please get a review of this change which does a tiny cleanup in the
> macosx specific code in `java_props_macosx.c`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8342647 the
> `setOSNameAndVersion` function used to dynamically call
> `NSProcessInfo.operatingSystemVersion` because
Can I please get a review of this change which does a tiny cleanup in the
macosx specific code in `java_props_macosx.c`?
As noted in https://bugs.openjdk.org/browse/JDK-8342647 the
`setOSNameAndVersion` function used to dynamically call
`NSProcessInfo.operatingSystemVersion` because that proper
On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy wrote:
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Comparing with https://github.com/openjdk/jdk/pull/21490 we can see that there
are more than minimum number of intrinsics I recommended above, but (crucially
On Fri, 18 Oct 2024 23:29:58 GMT, Shaojin Wen wrote:
> After PR 19970, the performance has been significantly improved. Below are
> the performance numbers for AMD CPU (x64)
It'd be interesting to check performance on this micro with #19970 alone
-
PR Comment: https://git.openjdk.
Port of Float16 from java.lang in the lworld+fp16 branch to
jdk.incubabor.vector.
-
Commit messages:
- Update with changes from lworld+fp16 Float16.
- Merge branch 'master' into JDK-8341260
- Add support for BigDecimal -> Float16 conversion.
- JDK-8341260: Add Float16 to jdk.incu
On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy wrote:
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Somebody might ask as a followup, "But what about calling sequences? Without
intrinsics, how does the JIT know to store Float16 values in the correct type
On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy wrote:
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Joe, our revised and now-current thinking about JIT support for the Float16
(both as a pre-Valhalla VBC and Valhalla value class) is that there should be
ze
On Thu, 17 Oct 2024 23:37:54 GMT, Joe Darcy wrote:
> ```
> $ diff test/jdk/java/lang/Float16/BasicFloat16ArithTests.java
> ~/jdk24/test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java
> 26c26,27
> < * @bug 8329817 8334432 8339076
> ---
> > * @bug 8329817 8334432 8339076 8341260
> > * @
On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy wrote:
> Port of Float16 from java.lang in the lworld+fp16 branch to
> jdk.incubabor.vector.
Add as contributors other engineers who worked on Float16 on the lworld+fp16
branch in Valhalla.
To ease review, diffs of corresponding files from the curre
Trivially removing some unused left-over `LambdaForm$Kind` enums.
- Last use of `COLLECT` and `SPREAD` was removed by fac39fe9
- `FIELD` was added by 8d5f5b9a but had no usage from the start
- Last use of `CONVERT` was removed by eda5f090
-
Commit messages:
- 8341776: Remove unused
On Sat, 19 Oct 2024 15:38:26 GMT, Claes Redestad wrote:
>> Lance Andersen has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add Combined test
>
> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
>
>> 721: * @return t
On Sat, 19 Oct 2024 16:28:34 GMT, Lance Andersen wrote:
>> Please review the changes for
>> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
>> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025)
>> which addresses that
>>
>> - ZipEntry(String)
>> - Z
On Sat, 19 Oct 2024 15:52:59 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/zip/ZipEntry.java line 723:
>>
>>> 721: * @return true if valid CEN Header size; false otherwise
>>> 722: */
>>> 723: static boolean isCENHeaderValid(String name, byte[] extra, String
> Please review the changes for
> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025) which
> addresses that
>
> - ZipEntry(String)
> - ZipEntry::setComment
> - ZipEntry::setExtra
>
> currently validat
On Fri, 18 Oct 2024 21:24:18 GMT, Lance Andersen wrote:
>> Please review the changes for
>> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
>> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025)
>> which addresses that
>>
>> - ZipEntry(String)
>> - Z
But *not letting any of them through into the forEach loop.
On Sat, Oct 19, 2024, 9:36 AM David Alayachew
wrote:
> So to be clear, I added a logger to my BufferedReader. So I know for a
> fact that it is reading data.
>
> And as for the code, it is a very simple parallel forEach.
>
> someStream.
So to be clear, I added a logger to my BufferedReader. So I know for a fact
that it is reading data.
And as for the code, it is a very simple parallel forEach.
someStream.parallel().forEach(**work**);
I only wanted to change the execution from sequential to parallel.
So I have millions and mill
On Sat, 19 Oct 2024 06:39:54 GMT, ExE Boss wrote:
>> This DMH is derived from invokerName, which comes from
>> java.lang.invoke.LambdaForm.Kind#defaultLambdaName
>
> `"NFI"` and `"LFI"` should probably also be added to this `switch`.
No: I believe these names are used for invokers spun exclusiv
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 18 Oct 2024 21:24:18 GMT, Lance Andersen wrote:
>> Please review the changes for
>> [JDK-8340553](https://bugs.openjdk.org/browse/JDK-8340553), which is a
>> follow-on to [JDK-8336025](https://bugs.openjdk.org/browse/JDK-8336025)
>> which addresses that
>>
>> - ZipEntry(String)
>> - Z
On Fri, 18 Oct 2024 23:13:27 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
>> line 141:
>>
>>> 139: case "MH" -> CD_MH;
>>> 140: case "DMH" -> CD_DMH;
>>> 141: case "BMH" -> CD_BMH;
>>
>> I don't see w
> Cache commonly used classDesc to avoid creating ReferenceClassDescImpl every
> time
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
add LFI/NFI
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21580/files
- new:
On Fri, 18 Oct 2024 15:47:16 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Better disinguish need for exhaustive scans
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 200
On Fri, 18 Oct 2024 14:42:39 GMT, Alexey Semenyuk wrote:
>> Make jpackage correctly handle the output directory (`--dest`) that is:
>> - a subdirectory of the input directory;
>> - the same as the input directory.
>>
>> Make jpackage correctly handle temp directory (`--temp`) that is:
>> - a
On Thu, 17 Oct 2024 22:44:05 GMT, Mandy Chung wrote:
>> The old core reflection implementation generates dynamic classes that are
>> special cases in the VM to bypass bytecode verification to workaround
>> various issues [1] [2] [3].
>>
>> The old core reflection implementation was [removed in
On Fri, 18 Oct 2024 17:18:05 GMT, Mandy Chung wrote:
>>> // If the loader is not the boot loader then throw an exception if its
>>> // superclass is in package jdk.internal.reflect
>>
>> This should not be needed. `jdk.internal.reflect` is a non-exported
>> package in `java.base` module. If
On Fri, 18 Oct 2024 21:43:49 GMT, Naoto Sato wrote:
>> Changing the charset initialization of `java.io.Console` class, which is the
>> basis of `java.io.IO`, so that it would behave the same way as `System.out`
>> wrt encoding. This change will also have the capability to override the
>> defau
Hi David. I am not a core libs team but I guess I can have some clues :).
It is hard to tell without the code, but I assume that there are a few
layers to it.
1. Stalling. I would assume it is caused mostly by GC pauses taking too
long (forever) if GC does not have any computational powers to run
28 matches
Mail list logo
