> Modify native multi-byte read-write code used by the `java.io` classes to
> limit the size of the allocated native buffer thereby decreasing off-heap
> memory footprint and increasing throughput.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
Instead of separate Hashtable.get/remove calls we can just use value returned
by `remove`,
It results in cleaner and a bit faster code.
-
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote:
> Time to start getting ready for JDK 20...
This pull request has now been integrated.
Changeset: edff51e5
Author:Joe Darcy
Committer: Erik Joelsson
URL:
https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557
On Thu, 9 Jun 2022 07:35:43 GMT, Andrey Turbanov wrote:
> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>
> Instead of separate Hashtable.get/remove calls we can just use value returned
> by
On Thu, 9 Jun 2022 16:04:43 GMT, Claes Redestad wrote:
>> To take optimal advantage of the pre-existing optimization for repeated
>> filters we could split the application of different types of stringifiers.
>>
>> The resulting difference in order of evaluation is not observable by
>>
On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
On Mon, 6 Jun 2022 06:57:23 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which addresses
> https://bugs.openjdk.java.net/browse/JDK-8285405?
>
> I've added the test for `LinkedHashMap.newLinkedHashMap(int)` in the existing
> `test/jdk/java/util/LinkedHashMap/Basic.java`
On Wed, 8 Jun 2022 09:39:04 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch implements intrinsics for `Integer/Long::compareUnsigned` using
>> the same approach as the JVM does for long and floating-point comparisons.
>> This allows efficient and reliable usage of unsigned comparison in
Please review this PR.
SDK 10.15 and earlier reports os.version as 10.16 on Big Sur. This fix will
check if dynamic linker support, which is supported from Big Sur, is available
or not on the OS even if os.version is reported as 10.16 instead of 11. The
os.version 10.16 doesn't include the
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a
On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad wrote:
> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All
> micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over
> with parameter
On Tue, 7 Jun 2022 12:34:25 GMT, Claes Redestad wrote:
> - Reduce runtime by running fewer forks, fewer iterations, less warmup. All
> micros tested in this group appear to stabilize very quickly.
> - Refactor BigIntegers to avoid re-running some (most) micros over and over
> with parameter
We still handle at a number of places ancient historic _MSC_VER versions of
Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
This should be cleaned up, as long as it is not 3rd party code that we don't
want to adjust.
Currently still supported ("valid") VS version are 2017+,
> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved
> flags is used
Thiago Henrique Hüpner has updated the pull request incrementally with one
additional commit since the last revision:
Update author
-
Changes:
- all:
On Tue, 7 Jun 2022 12:19:29 GMT, Magnus Ihse Bursie wrote:
> The test
> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
> verifies different failure modes of resource bundles. One of the failures is
> that the runner class, `MissingResourceCauseTestRun.java`,
On Wed, 8 Jun 2022 17:43:49 GMT, Naoto Sato wrote:
>> The test
>> `test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTest.java`
>> verifies different failure modes of resource bundles. One of the failures is
>> that the runner class, `MissingResourceCauseTestRun.java`, creates a
On Tue, 7 Jun 2022 14:15:55 GMT, Gaurav Chaudhari wrote:
>> This fix ensures that when a lookup for a custom TZ code fails, and an
>> attempt is made to find the GMT offset in order to get the current time,
>> Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the
> To take optimal advantage of the pre-existing optimization for repeated
> filters we could split the application of different types of stringifiers.
>
> The resulting difference in order of evaluation is not observable by
> conventional means since all reference type share the same object
>
My main concerns are about security, that many object details, while
useful to viewers, should not be accessible by any code under any
circumstances. Having any code able to print all field content of any
object sounds extremely dangerous.
In my opinion, we can use a MethodHandles.Lookup as a
19 matches
Mail list logo
