> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the
On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically,
On Wed, 25 Nov 2020 16:22:34 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 151:
>>
>>> 149: if (fm == null) {
>>> 150: synchronized (RandomGeneratorFactory.class) {
>>> 151: if
On Sat, 21 Nov 2020 09:21:06 GMT, John Lin
wrote:
>> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else
>> will have to do that for you. Might as well be me. So here's my proposal:
>> come up with the meat, then I'll help you with the paperwork.
>>
>> For starters,
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 13:55:52 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line
>> 453:
>>
>>> 451: * @return a {@code RandomGenerator} object that uses {@code
>>> ThreadLocalRandom}
>>> 452: */
>>> 453: public static
On Wed, 25 Nov 2020 15:43:39 GMT, Jim Laskey wrote:
>> will investigate
>
> Needed to use ThreadLocalRandomProxy.proxy otherwise a cast would be required.
yes, right !
-
PR: https://git.openjdk.java.net/jdk/pull/1292
On Wed, 25 Nov 2020 13:38:59 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
The ByteBuffers micro benchmark seems to be a little dated.
It should be a useful resource to leverage when analysing the performance
impact of any potential implementation changes in the byte buffer classes. More
specifically, the impact of such changes on the performance of sharp memory
On Wed, 25 Nov 2020 13:31:52 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
On Wed, 4 Nov 2020 19:29:34 GMT, Lance Andersen wrote:
>> Vipin Sharma has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated copyright year and other issues reporrted in review
>
> Marked as reviewed by lancea (Reviewer).
I think all
This is a corner case that arises when creating a Configuration for a child
module layer. If an explicit module in the child configuration reads an
automatic module in a parent configuration then it should read all automatic
modules in the parent configurations. Unfortunately, this read edge
On Wed, 25 Nov 2020 13:12:34 GMT, Claes Redestad wrote:
> I do wonder if there's some value to at least some of these noisy, allocating
> variants, though. Could be interesting to zoom in on code where we allocate
> transient, small buffers, e.g. when encoding/decoding strings. But perhaps
>
On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically,
On Fri, 16 Oct 2020 19:38:45 GMT, Vipin Sharma wrote:
> ... is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.
This pull request has now been integrated.
Changeset: dee79d60
Author:Vipin Sharma
Committer: Lance Andersen
URL:
On Wed, 25 Nov 2020 00:01:47 GMT, David Holmes wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 10 additional
>> commits
- Mail original -
> De: "Stuart Marks"
> À: "core-libs-dev"
> Envoyé: Mardi 24 Novembre 2020 08:10:14
> Objet: Re: RFR: 8180352: Add Stream.toList() method [v4]
>> This change introduces a new terminal operation on Stream. This looks like a
>> convenience method for
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 15:59:01 GMT, Jim Laskey wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java
>> line 88:
>>
>>> 86: * {@code
>>> 87: * RandomGeneratorFactory best =
>>> RandomGenerator.all()
>>> 88: * .sorted((f, g) ->
On Wed, 25 Nov 2020 12:16:01 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Pass in thread instead of rematerializing it.
>
> src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33:
>
>>
On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically,
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Tue, 24 Nov 2020 03:46:38 GMT, Stuart Marks wrote:
>> In `ReferencePipeline` class we have:
>>
>> @Override
>> public final Object[] toArray() {
>> return toArray(Object[]::new);
>> }
>>
>> @Override
>> @SuppressWarnings("unchecked")
>> public final A[]
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 13:37:48 GMT, Maurizio Cimadamore
wrote:
> Looks like a good cleanup. I agree that mixing access and instantiation is
> not good from a benchmark perspective - although, given that direct buffers
> have a rather convoluted allocation process, I guess it would be useful, in
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee wrote:
>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
>> the needed changes to get it working again.
>>
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
>> macro. Using just JNI_ENTRY was
On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty wrote:
> The ByteBuffers micro benchmark seems to be a little dated.
>
> It should be a useful resource to leverage when analysing the performance
> impact of any potential implementation changes in the byte buffer classes.
> More specifically,
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 10:01:15 GMT, Vladimir Ivanov wrote:
>> The information that there was a barrier attached, is implicit in the
>> ins_encode block due to it being run at all. In other words, since we
>> matched the mach node to our ZGC access instead of a normal access, we
>> already know
On Tue, 24 Nov 2020 23:00:05 GMT, Mandy Chung wrote:
>> I agree. This @apiNote needs more clarification to help the readers to
>> understand the context here.One thing we could do in the Package class
>> description to add a "Package Sealing" section that can also explain that it
>> has
On Wed, 25 Nov 2020 13:24:37 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
On Wed, 25 Nov 2020 13:09:03 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Wed, 25 Nov 2020 08:43:04 GMT, Vladimir Ivanov wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
On Wed, 25 Nov 2020 13:37:02 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
On Wed, 25 Nov 2020 06:19:04 GMT, Stuart Marks wrote:
>>> The proposed CSR has a few problems that we need to resolve.
>>>
>>> 1. The **Specification** pseudo-code behaves differently from both the old
>>> pseudo-code and the actual implementation when `newValue == null &&
>>> oldValue ==
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was causing a linkage failure, due to the
> declaration of the
On Wed, 25 Nov 2020 15:13:11 GMT, Erik Österlund wrote:
>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 623:
>>
>>> 621: // Also we need to add memory barrier to prevent commoning reads
>>> 622: // from this field across safepoint since GC can change its value.
>>> 623: bool
On Wed, 25 Nov 2020 16:39:20 GMT, Pavel Rappo wrote:
>> @pavelrappo Please see my proposed CSR below. Thank you.
>>
>> # Map::compute should have a clearer implementation requirement.
>>
>> ## Summary
>>
>> java.util.Map::compute should have a clearer implementation requirement in
>> its
On Tue, 24 Nov 2020 07:10:14 GMT, Stuart Marks wrote:
>> This change introduces a new terminal operation on Stream. This looks like a
>> convenience method for Stream.collect(Collectors.toList()) or
>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>> method
On Wed, 25 Nov 2020 19:52:21 GMT, Aleksey Shipilev wrote:
> Your PR have also been bitten by #1427, merge from master to get it fixed.
Thanks! I will apply your patch and merge from master latest changes.
-
PR: https://git.openjdk.java.net/jdk/pull/1425
On Wed, 25 Nov 2020 16:30:16 GMT, Jorn Vernee wrote:
>> The VM "entry" changes seem better now. Thanks.
>>
>> The use of CATCH as a safety-net is also good.
>
> I've applied open comments. Please let me know if this is ok to merge.
Still looks fine to me. Merge from master to get the fixes for
On Wed, 25 Nov 2020 14:07:07 GMT, Peter Levart wrote:
>> This is the default implementation in the Stream interface, which is
>> overridden by an implementation in the ReferencePipeline class, so it will
>> rarely be used in normal operation. The ReferencePipeline version (part of
>> this
On Wed, 25 Nov 2020 11:09:05 GMT, Per Liden wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
>>
On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee wrote:
> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains
> the needed changes to get it working again.
>
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV`
> macro. Using just JNI_ENTRY was
On Wed, 25 Nov 2020 17:05:15 GMT, Aleksey Shipilev wrote:
>> I've applied open comments. Please let me know if this is ok to merge.
>
> Still looks fine to me. Merge from master to get the fixes for GH actions
> failures, #1427
Thanks, Jorn. The split looks good.
-
PR:
On Wed, 25 Nov 2020 19:48:32 GMT, Jim Laskey wrote:
>> At least, it's more clear that it's reversed, i've initially miss the fact
>> that f and g are swapped.
>> And :: is able to do inference so, i believe it can be written
>>
>>
On Wed, 25 Nov 2020 13:45:46 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
On Wed, 25 Nov 2020 13:54:47 GMT, Rémi Forax
wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8248862: Implement Enhanced Pseudo-Random Number Generators
>>
>> Changes to RandomGeneratorFactory requested by
On Wed, 25 Nov 2020 19:48:40 GMT, Aleksey Shipilev wrote:
>>> I just pulled the fresh master, applied this patch on top, enabled
>>> `_PhantomReference_refersTo0` in `c2compiler.cpp`, and ran
>>> `CONF=linux-x86_64-server-fastdebug make images run-test TEST=tier1
>>>
Defined new test groups as defined in ticket. @fguallini
-
Commit messages:
- 8256894: removing manual tests from corelibs tests
- 8256894: define test groups
Changes: https://git.openjdk.java.net/jdk/pull/1416/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1416=00
On Wed, 25 Nov 2020 11:05:39 GMT, Per Liden wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
>>
This patch fixes several failures on x86_32 of java/foreign tests.
This is mostly done by disabling the failing tests, but the impl of CLinker is
also adjusted ton properly detect 32 bit platforms as unsupported.
CLinker is specified to fail in the initializer on unsupported platforms, and a
On Wed, 25 Nov 2020 18:07:34 GMT, Vladimir Kozlov wrote:
>> I don't think we have any !in_heap && on_weak loads today. But if we did,
>> they would indeed need read barriers.
>> We need read barrier if the the reference isn't provably strong... unless
>> it's an AS_NO_KEEPALIVE access. That
On Wed, 25 Nov 2020 20:13:48 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here an almost trivial fix for:
> 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly
> delay
>
> The two tests are changed from using Math.random() to using the jdk test lib
> RandomFactory,
> java.util.HexFormat utility:
>
> - Format and parse hexadecimal strings, with parameters for delimiter,
> prefix, suffix and upper/lowercase
> - Static factories and builder methods to create HexFormat copies with
> modified parameters.
> - Consistent naming of methods for conversion of
On Wed, 25 Nov 2020 22:00:13 GMT, Jorn Vernee wrote:
>> This patch fixes several failures on x86_32 of java/foreign tests.
>>
>> This is mostly done by disabling the failing tests, but the impl of CLinker
>> is also adjusted ton properly detect 32 bit platforms as unsupported.
>>
>> CLinker
On Wed, 25 Nov 2020 23:50:14 GMT, Mark Reinhold wrote:
>> Please review this implementation of JEP 396
>> (https://openjdk.java.net/jeps/396).
>> Alan Bateman is the original author; I’ve credited him in the commit
>> metadata.
>> Passes tiers 1-3 on {linux,macos,windows}-x64 and
> This patch fixes several failures on x86_32 of java/foreign tests.
>
> This is mostly done by disabling the failing tests, but the impl of CLinker
> is also adjusted ton properly detect 32 bit platforms as unsupported.
>
> CLinker is specified to fail in the initializer on unsupported
> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
>
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
>
On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs wrote:
>> java.util.HexFormat utility:
>>
>> - Format and parse hexadecimal strings, with parameters for delimiter,
>> prefix, suffix and upper/lowercase
>> - Static factories and builder methods to create HexFormat copies with
>> modified
On Wed, 25 Nov 2020 15:07:21 GMT, Erik Österlund wrote:
>> Ok, makes sense. What do you think about making `ZLoadBarrierElided = 0`
>> then?
>
> I'm okay with that. I don't have a strong preference.
I also prefer to have ZLoadBarrierElided = 0. I will add it.
-
PR:
On Wed, 25 Nov 2020 08:18:23 GMT, Vladimir Ivanov wrote:
>> src/hotspot/share/opto/c2compiler.cpp line 476:
>>
>>> 474: if (UseCompressedOops && UseShenandoahGC) return false;
>>> 475: #endif
>>> 476: break;
>>
>> Is this intended to disable the intrinsic on all non-64-bit platforms?
Hi,
Please find here an almost trivial fix for:
8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay
The two tests are changed from using Math.random() to using the jdk test lib
RandomFactory, which prints its seed in the log file and allows for better
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
On Wed, 25 Nov 2020 22:24:40 GMT, Mandy Chung wrote:
>> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
>> the given default method on the given proxy instance.
>>
>> The implementation looks up a method handle for `invokespecial` instruction
>> as if called from with
On Fri, 20 Nov 2020 13:08:11 GMT, Alan Bateman wrote:
>> Looks good.
>
> testWithAddExportsInManifest create an executable JAR with "Add-Exports:
> java.base/sun.security.x509" in the manifest. It runs it twice, once without
> any options, the second with --illegal-access=permit, and checks
> Please review this implementation of JEP 396
> (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I’ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
Mark Reinhold has updated the pull request incrementally with
On Mon, 23 Nov 2020 15:27:52 GMT, Alan Bateman wrote:
> This is a corner case that arises when creating a Configuration for a child
> module layer. If an explicit module in the child configuration reads an
> automatic module in a parent configuration then it should read all automatic
>
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
On Wed, 25 Nov 2020 16:26:12 GMT, Rémi Forax
wrote:
>> Not sure that
>> `.sorted(Comparator.comparingInt(RandomGeneratorFactory::stateBits).reversed())`
>> is simpler than `.sorted((f, g) -> Integer.compare(g.stateBits(),
>> f.stateBits()))`.
>
> At least, it's more clear that it's
On Wed, 25 Nov 2020 18:34:28 GMT, Erik Österlund wrote:
>> From this conversation the only change I can do is 'Turn (on_weak ||
>> on_phantom) into !on_strong'.
>> @fisk Is this correct? I am concern that it will include `unknown` decorator
>> too.
>> I agree with Erik to keep !no_keepalive
On Wed, 25 Nov 2020 17:48:54 GMT, Vladimir Kozlov wrote:
> @shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.
That sounds like a testbug to me! Since this PR adds C2 intrinsics, I thought
it is expected that new tests trigger it in default test configs...
> You need
On Wed, 25 Nov 2020 19:05:19 GMT, Stuart Marks wrote:
>> @johnlinp In any case, you'd also need to update the surrounding prose; we
>> need to remove this:
>> returning the current value or {@code null} if absent:```
>
> @pavelrappo
>
>> What is the required level of fidelity particular
On Tue, 24 Nov 2020 16:13:59 GMT, Ivan Šipka wrote:
> Defined new test groups as defined in ticket. @fguallini
test/jdk/TEST.groups line 327:
> 325: :core_tools \
> 326: :jdk_other \
> 327: :jdk_core_manual
Please don't add manual tests to jdk_core.
-
PR:
On Wed, 25 Nov 2020 11:19:27 GMT, Alan Bateman wrote:
>> Defined new test groups as defined in ticket. @fguallini
>
> test/jdk/TEST.groups line 327:
>
>> 325: :core_tools \
>> 326: :jdk_other \
>> 327: :jdk_core_manual
>
> Please don't add manual tests to jdk_core.
Removed.
On Wed, 25 Nov 2020 07:58:42 GMT, Aleksey Shipilev wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote:
> This change terminally deprecates the following methods defined by
> java.lang.ThreadGroup
>
> - stop
> - destroy
> - isDestroyed
> - setDaemon
> - isDaemon
>
> The stop method has been deprecated since=1.2 because it is inherently
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty wrote:
> Minor cleanup - Reflective access to j.l.Record is no longer required since
> it became standard.
This pull request has now been integrated.
Changeset: cdb41ba1
Author:Chris Hegarty
URL:
> Original mail:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>
> Hello,
>
> while working with `StringBuilder.insert()` I've spotted that its delegate
> `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument
On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore
wrote:
> Both the Foreign Memory Access and the Foreign Linker APIs leave something to
> be desired when it comes to handling NPEs - first, most of the API javadoc is
> oblivious to NPEs being thrown. Secondly, not all API method
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov wrote:
> JDK-8188055 added the function Reference.refersTo. For performance, the
> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
> should be intrinsified by C2.
>
> Initial patch was prepared by @fisk.
>
>
On Wed, 25 Nov 2020 08:58:21 GMT, Сергей Цыпанов
wrote:
>> Original mail:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>>
>> Hello,
>>
>> while working with `StringBuilder.insert()` I've spotted that its delegate
>> `AbstractStringBuilder.insert()` is
On Tue, 24 Nov 2020 23:59:11 GMT, David Holmes wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 10 additional
>> commits
On Tue, 24 Nov 2020 16:01:15 GMT, Maurizio Cimadamore
wrote:
>> Both the Foreign Memory Access and the Foreign Linker APIs leave something
>> to be desired when it comes to handling NPEs - first, most of the API
>> javadoc is oblivious to NPEs being thrown. Secondly, not all API method
>>
On Wed, 25 Nov 2020 08:30:46 GMT, Vladimir Ivanov wrote:
>> JDK-8188055 added the function Reference.refersTo. For performance, the
>> supporting native methods Reference.refersTo0 and PhantomReference.refersTo0
>> should be intrinsified by C2.
>>
>> Initial patch was prepared by @fisk.
>>
On Wed, 25 Nov 2020 09:47:19 GMT, Erik Österlund wrote:
>> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
>>
>>> 121:
>>> 122: ins_encode %{
>>> 123: if (barrier_data() != 0) { // barrier could be elided by
>>> ZBarrierSetC2::analyze_dominating_barriers()
>>
>> Maybe keep a bit
93 matches
Mail list logo
