Re: RFR: 8258422: Cleanup unnecessary null comparison before instanceof check in java.base [v4]
On Thu, 17 Dec 2020 13:16:31 GMT, Aleksei Efimov wrote: >> Andrey Turbanov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8258422: Cleanup unnecessary null comparison before instanceof check in >> java.base >> take advantage of "flow scoping" to eliminate casts > > Thank you for checking `HttpURLConnection` and `Socket`. > The latest version looks good to me. This issue is blocked by [8258657][1]. It should not be integrated until after 8258657 has been resolved. The JIRA issues have been linked up to reflect this. [1]: https://bugs.openjdk.java.net/browse/JDK-8258657 - PR: https://git.openjdk.java.net/jdk/pull/20
Re: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2]
On Thu, 17 Dec 2020 16:14:56 GMT, Roger Riggs wrote: > Disabling all of the tests on 32 bit is not a good idea. > > Instead the HexFormatTest.testOOME test should be skipped or the OOME should > be ignored. > Checking Runtime.getRuntime().maxMemory() should provide enough info to skip > it. Thanks @RogerRiggs for your review and comments. Let's ignore the OOME for testOOME. What do you think of the updated change? Thanks. - PR: https://git.openjdk.java.net/jdk/pull/1817
Re: RFR: 8258584: java/util/HexFormat/HexFormatTest.java fails on x86_32 [v2]
> Hi all, > > java/util/HexFormat/HexFormatTest.java fails on x86_32 due to '-Xmx4G'. > The reason is that -Xmx4G is invalid maximum heap size for 32-bit platforms. > The current implementation only supports maximum 3800M on 32-bit systems [1]. > > I've tried to reduce the -Xmx size, but it still fails even with -Xmx2G. > So this test seems to be brittle on 32-bit platforms since 2G is already > larger than 3800M/2=1900M. > The fix just skips the test for 32-bit systems. > > Thanks. > Best regards, > Jie > > [1] > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/os_posix.cpp#L567 Jie Fu has updated the pull request incrementally with two additional commits since the last revision: - Ignore OOME for testOOME - Revert the change - Changes: - all: https://git.openjdk.java.net/jdk/pull/1817/files - new: https://git.openjdk.java.net/jdk/pull/1817/files/6b32101d..38d4d01a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1817=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1817=00-01 Stats: 8 lines in 1 file changed: 0 ins; 6 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1817.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1817/head:pull/1817 PR: https://git.openjdk.java.net/jdk/pull/1817
Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll
On Thu, 17 Dec 2020 10:36:17 GMT, Rémi Forax wrote: >> Looks like I've found the original ticket: >> https://bugs.openjdk.java.net/browse/JDK-8193031 > > Apart from the @SuppressWarnings, this looks good to me. > And i like the irony of this. Hi all, According to the document of [SafeVarargs](https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/SafeVarargs.html). > Compilers are encouraged to issue warnings when this annotation type is > applied to a method or constructor declaration where: > The body of the method or constructor declaration performs potentially unsafe > operations, such as an assignment to an element of the variable arity > parameter's array that generates an unchecked warning. The `SafeVarargs` may not suppress the warning of this assignment and the `SuppressWarnings` may be necessary. If you still think it is the bug of compiler. I suggest that you move the bug discussion to the compiler-...@openjdk.java.net to solve the bug as soon as possible. - PR: https://git.openjdk.java.net/jdk/pull/1764
