On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote:
> `AccessibleObject::setAccessible` and `trySetAccessible` methods should only
> allow access to public member of a public type that is unconditionally
> exported consistent with the access check as described in the class
> specification,
On Fri, 28 Jan 2022 17:50:19 GMT, Mandy Chung wrote:
> `AccessibleObject::setAccessible` and `trySetAccessible` methods should only
> allow access to public member of a public type that is unconditionally
> exported consistent with the access check as described in the class
> specification,
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from
On Tue, 25 Jan 2022 05:25:12 GMT, Joe Darcy wrote:
>> Making the exception message friendlier to users.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Looks good.
I see Mandy has suggested the
On Tue, 25 Jan 2022 02:42:45 GMT, Joe Darcy wrote:
> Making the exception message friendlier to users.
src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 387:
> 385: msg += "a member of " + memberClass + memberSuffix +
> 386: (packageAccess ?
>
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from
On Tue, 25 Jan 2022 00:20:19 GMT, Yumin Qi wrote:
> Please review,
> When jlink with --compress=2, zip is used to compress the files while doing
> copy. The user case failed to load zip.dll, since zip.dll is not set in PATH.
> This failure is after we get NULL from
On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote:
> Tests were fatally failing (windows) on Github actions. Pumping up the memory
> requirements will hopefully alleviate.
Okay - lets see how it goes.
Thanks,
David
-
Marked as reviewed by dholmes (Reviewer).
PR:
On Fri, 14 Jan 2022 14:33:13 GMT, Jim Laskey wrote:
> Tests were fatally failing (windows) on Github actions. Pumping up the memory
> requirements will hopefully alleviate.
I also pointed out that we see the same error message in our CI and the infra
folk assured me that the paging file was
On Sun, 19 Dec 2021 07:37:19 GMT, Alan Bateman wrote:
>> Enable the security manager in rmiregistry's launcher arguments.
>
> As things stand, `rmiregsitry -J-Djava.security.manager` and `rmiregistry
> -J-Djava.security.manager=allow` are equivalent because rmiregistry sets the
> default SM.
On Sun, 19 Dec 2021 06:51:45 GMT, liach wrote:
>> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
>> by design, duplicate initialization of ReflectionFactory should be safe as
>> it performs side-effect-free property read actions, and the suggesting of
>> making
On Sun, 19 Dec 2021 07:05:31 GMT, liach wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 695:
>>
>>> 693:
>>> 694: // ensure previous fields are visible before initted is
>>> 695: Unsafe.getUnsafe().storeStoreFence();
>>
>> Ensuring
On Sun, 19 Dec 2021 03:21:55 GMT, liach wrote:
> Upon review of [8261407](https://bugs.openjdk.java.net/browse/JDK-8261407),
> by design, duplicate initialization of ReflectionFactory should be safe as it
> performs side-effect-free property read actions, and the suggesting of making
> the
On Wed, 15 Dec 2021 17:56:23 GMT, Vladimir Kozlov wrote:
>> A proper fix for this is to use the catchException combination. However,
>> that introduces significant cold startup performance regression. JDK-8278447
>> tracks the work to address the performance regression using catchException
>>
On Wed, 15 Dec 2021 05:59:45 GMT, Vladimir Kozlov wrote:
> A proper fix for this is to use the catchException combination. However, that
> introduces significant cold startup performance regression. JDK-8278447
> tracks the work to address the performance regression using catchException
> and
Investigation showed this test was experiencing interference from threads
created by other tests in agentvm mode. The simple solution is to run this test
isolated using othervm mode. Also added some diagnostics to the test incase we
see future failures.
Testing: local and tier3.
Thanks,
David
On Fri, 10 Dec 2021 02:48:43 GMT, Jonathan Gibbons wrote:
>> Please review this semi-automatic update for the nroff man pages for JDK 18.
>> The changes update the version number, copyright year, and incorporate the
>> changes from the latest upstream files.
>
> We will also want to
On Fri, 10 Dec 2021 01:46:03 GMT, Jonathan Gibbons wrote:
> Please review this semi-automatic update for the nroff man pages for JDK 18.
> The changes update the version number, copyright year, and incorporate the
> changes from the latest upstream files.
Hi Jon,
This all looks good - I'm
On Mon, 6 Dec 2021 09:11:07 GMT, Aleksey Shipilev wrote:
>>> I've solicited feedback from core-libs folk as this affects them the most.
>>> At present we, Oracle, run the jdk_svc tests as part of hotspot testing,
>>> but this change will suddenly cause jdk testing to include them. That is
>>>
On 2/12/2021 6:25 pm, Aleksey Shipilev wrote:
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
All right then. Thanks for followups!
Hi Aleksey,
I've solicited feedback from core-libs folk as this affects them the
most. At present we, Oracle, run the jdk_svc tests as part of
On Thu, 2 Dec 2021 02:00:11 GMT, Mikhailo Seledtsov
wrote:
>> Hi @shipilev ,
>> We need to have someone look at the impact of this on our CI. I don't think
>> we run the tier4 group as defined in our tier 4 so we may not see those
>> execution time savings that offset the extra cost to tier3.
On Tue, 30 Nov 2021 18:48:15 GMT, Aleksey Shipilev wrote:
> OpenJDK tiered tests definitions have the catch-all `tier4` that runs all
> tests not defined in the lower tiers. `hotspot:tier4` has lots of them,
> mostly long-running vmTestbase tests, which take many hours even on a very
>
On Tue, 30 Nov 2021 14:52:37 GMT, Alan Bateman wrote:
> Thread.stop is inherently unsafe and has been deprecated since Java 1.2
> (1998). It's time to terminally deprecate this method so it can be degraded
> and removed in the future.
>
> This PR does not propose any changes to the JVM TI
On 1/12/2021 3:13 am, Alan Snyder wrote:
Although I understand the potential dangers of using Thread.stop, it seems to
me there are cases where its use is legitimate and valuable.
No there really aren't. :) The perceived utility of stop() is an
illusion. It is almost impossible to write any
On 26/11/2021 4:15 am, kabutz wrote:
On Thu, 18 Nov 2021 07:26:45 GMT, David Holmes wrote:
kabutz has updated the pull request incrementally with one additional commit
since the last revision:
Removed JVM flags from benchmark
To add my 2c IMO a parallel version of this type absolutely
On Tue, 23 Nov 2021 19:23:40 GMT, Joe Darcy wrote:
>> The time to get JDK 19 underway draws nigh, please review this usual set of
>> start-of-release updates, including CSRs for the javac and javax.lang.model
>> updates:
>>
>> JDK-8277512: Add SourceVersion.RELEASE_19
>>
On Mon, 22 Nov 2021 04:30:38 GMT, Joe Darcy wrote:
>> The time to get JDK 19 underway draws nigh, please review this usual set of
>> start-of-release updates, including CSRs for the javac and javax.lang.model
>> updates:
>>
>> JDK-8277512: Add SourceVersion.RELEASE_19
>>
On Mon, 22 Nov 2021 03:15:51 GMT, Joe Darcy wrote:
> The time to get JDK 19 underway draws nigh, please review this usual set of
> start-of-release updates, including CSRs for the javac and javax.lang.model
> updates:
>
> JDK-8277512: Add SourceVersion.RELEASE_19
>
On Fri, 19 Nov 2021 20:13:06 GMT, Stuart Marks wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove Finalizer.Holder class.
>
> Regarding **jcmd** updates, I'm thinking maybe this would be better handled
>
On Fri, 19 Nov 2021 02:29:33 GMT, Stuart Marks wrote:
>>> When the finalization is disabled, perhaps jcmd GC.finalizer_info should
>>> just be made as a nop in the VM.
>>
>> Yes that is a trivial change to add. @stuart-marks I can provide the code.
>> You can choose whether to include in this
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Thu, 18 Nov 2021 23:36:23 GMT, Brent Christian wrote:
> When the finalization is disabled, perhaps jcmd GC.finalizer_info should just
> be made as a nop in the VM.
Yes that is a trivial change to add. @stuart-marks I can provide the code. You
can choose whether to include in this PR or
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
On Thu, 18 Nov 2021 20:05:15 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
Hi Mandy,
On 19/11/2021 6:16 am, Mandy Chung wrote:
On Thu, 18 Nov 2021 06:49:03 GMT, Kim Barrett wrote:
src/hotspot/share/prims/jvm.cpp line 694:
692:
693: JVM_ENTRY(jboolean, JVM_IsFinalizationEnabled(JNIEnv * env))
694: return InstanceKlass::finalization_enabled() ? JNI_TRUE :
On Thu, 18 Nov 2021 07:44:05 GMT, Aleksey Shipilev wrote:
>> @shipilev not sure what you mean by "a flag on the Java side". The Java
>> code just queries the VM for the finalization enabled/disabled state and
>> uses that to control things.
>
> Yeah, "flag" is `Holder.ENABLED` here. I mean,
On Thu, 18 Nov 2021 07:16:56 GMT, Kim Barrett wrote:
> There is nothing here to make the various GCs take advantage of finalization
> being disabled. Is the plan to leave that to followup changes?
@kimbarrett I provided the basic VM parts here. I'm not aware of what
specifically a GC might
On Thu, 18 Nov 2021 07:27:30 GMT, Aleksey Shipilev wrote:
>> @stuart-marks not sure I see how anything is different here compared to the
>> existing logic. The `Finalizer` class is explicitly initialized quite early
>> in the init process, but if a preceding class's initialization created an
On Wed, 17 Nov 2021 19:48:25 GMT, kabutz wrote:
>> BigInteger currently uses three different algorithms for multiply. The
>> simple quadratic algorithm, then the slightly better Karatsuba if we exceed
>> a bit count and then Toom Cook 3 once we go into the several thousands of
>> bits. Since
On Thu, 18 Nov 2021 05:20:02 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/lang/ref/Finalizer.java line 195:
>>
>>> 193:
>>> 194: static {
>>> 195: if (Holder.ENABLED) {
>>
>> Hello Stuart,
>> My understanding of the the lazy `Holder` is that it's there to delay the
On Thu, 18 Nov 2021 01:34:36 GMT, Stuart Marks wrote:
> Pretty much what it says. The new option controls a static member in
> InstanceKlass that's consulted to determine whether the finalization
> machinery is activated for instances when a class is loaded. A new native
> method is added so
On 15/11/2021 8:14 pm, Alan Bateman wrote:
On 15/11/2021 09:48, David Holmes wrote:
I think there may be a misunderstanding here, AFAICS they are using
reflection to remove the final-ness of a field in their own classes,
not modifying anything in Class or Field.
That's the outcome. To get
Hi Alan,
On 15/11/2021 5:11 pm, Alan Bateman wrote:
On 14/11/2021 22:56, Claes Redestad wrote:
:
Alan: changing `Field.modifiers` still works, but dropping the final
modifier is not enough for this to work in the new impl. It won't be
hard to adapt to the new world. Users who relies on this
On Thu, 4 Nov 2021 11:09:42 GMT, Magnus Ihse Bursie wrote:
> I ran bin/blessed-modifier-order.sh on source owned by core-libs. This
> scripts verifies that modifiers are in the "blessed" order, and fixes it
> otherwise. I have manually checked the changes made by the script to make
> sure
.html
(or https://github.com/openjdk/jdk/pull/6191#pullrequestreview-79465)
[^2]:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035217.html
_Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
[core-libs-dev](mailto:core-libs
On Thu, 4 Nov 2021 01:34:01 GMT, Igor Ignatyev wrote:
>>> That doesn’t seem right as jtreg expects `-` not
>>> ``
>>
>> It has been tested, details in ticket comment.
>
> I’m sorry @frkator but there is nothing in the ticket.
@iignatev the comment is confidential as it refers to internal
On Mon, 1 Nov 2021 07:36:53 GMT, Aleksey Shipilev wrote:
>> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
>> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed
>> (useless?) to call to runtime for a single memory barrier. We can simplify
>> the native `Unsafe`
On Wed, 27 Oct 2021 09:57:43 GMT, swati sharma wrote:
> 8276048: Error in javadoc regarding Long method public static Long
> valueOf(String s)
> Fix: Changing integer to {@code Long}
I agree with Joe there is nothing to fix here - "integer" is general
mathematical term. If it were "int" or
On 3/11/2021 9:26 pm, Pavel Rappo wrote:
On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote:
Pragmatically, fix the script to ignore those keywords on comment lines. Learn
Perl, its just a regular expression pattern match and replace expression.
I understand in principle how to modify
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe`
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
> `Unsafe`
On Thu, 28 Oct 2021 07:00:24 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/jdk/internal/misc/Unsafe.java line 3449:
>>
>>> 3447: public final void storeStoreFence() {
>>> 3448: // Without the special intrinsic, default to a stronger
>>> storeFence,
>>> 3449:
On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote:
> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
> We can teach compilers to map this directly to already existing rules that
> handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we
>
On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote:
> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
> We can teach compilers to map this directly to already existing rules that
> handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we
>
On Tue, 26 Oct 2021 22:51:29 GMT, Mandy Chung wrote:
> On, macOS 11.x, system libraries are loaded from dynamic linker cache. The
> libraries are no longer present on the filesystem.
> `NativeLibraries::loadLibrary` checks for the file existence before calling
> `JVM_LoadLibrary`. Such
On Tue, 19 Oct 2021 17:12:16 GMT, Harold Seigel wrote:
> Please review this small fix for JDK-8272614 to remove the unused indexInCP
> argument to linkCallSite() and linkDynamicConstant(). The fix was tested
> with Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-6 on
> Linux
On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
On 14/10/2021 6:27 pm, Andrew Haley wrote:
On Thu, 14 Oct 2021 07:08:20 GMT, David Holmes wrote:
The issue is only on (some of) our macOS Aarch64 systems. Let me know if I can
provide more info on hardware etc.
Any info about what failed? A reproducer would be nice.
See https
On 14/10/2021 4:55 pm, Nick Gasson wrote:
On Thu, 14 Oct 2021 06:48:18 GMT, David Holmes wrote:
This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
which caused some unknown failures in Oracle's CI.
Thanks for attending to this so quickly @nick-arm !
On Thu, 14 Oct 2021 06:37:19 GMT, Nick Gasson wrote:
> This reverts "8269559: AArch64: Implement string_compare intrinsic in SVE"
> which caused some unknown failures in Oracle's CI.
Thanks for attending to this so quickly @nick-arm !
The issue is only on (some of) our macOS Aarch64 systems.
On 14/10/2021 4:28 pm, Nick Gasson wrote:
On Thu, 14 Oct 2021 01:17:17 GMT, TatWai Chong wrote:
This patch implements string_compare intrinsic in SVE.
It supports all LL, LU, UL and UU comparisons.
As we haven't found an existing benchmark to measure performance impact,
we created a
We are seeing a large number of Aarch64 test failures in our CI after
this push. Somewhat bizarre failure modes:
- truncated classfiles
- unexpected EOF encountered
- illegal state reading a stream
I think we will need to back this change out while this is investigated
further.
David
-
On 8/10/2021 6:10 am, Andrey Turbanov wrote:
Hello.
I found suspicious code in the method
sun.reflect.generics.parser.SignatureParser#parseBounds
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java#L532
Method 'error' called
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote:
> The OS detection code of the JDK/JVM should recognize the new Windows 11. For
> details see :
>
> https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
> OS build number is : 22000.194 for 21H2 (original
On Fri, 1 Oct 2021 00:28:55 GMT, David Holmes wrote:
> A regression introduced in Java 17 will give the default FJ pool a
> parallelism of zero in a uniprocessor environment. The fix restores this to a
> value of 1. See bug report for details.
>
> Testing:
> - new regressi
On Fri, 1 Oct 2021 06:21:51 GMT, Aleksey Shipilev wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Updated TCK test component from @martin
>
> Oh wow. Looks good!
Thanks for the
> A regression introduced in Java 17 will give the default FJ pool a
> parallelism of zero in a uniprocessor environment. The fix restores this to a
> value of 1. See bug report for details.
>
> Testing:
> - new regression test
> - tiers 1-3
>
> Thanks,
> D
> A regression introduced in Java 17 will give the default FJ pool a
> parallelism of zero in a uniprocessor environment. The fix restores this to a
> value of 1. See bug report for details.
>
> Testing:
> - new regression test
> - tiers 1-3
>
> Thanks,
> D
A regression introduced in Java 17 will give the default FJ pool a parallelism
of zero in a uniprocessor environment. The fix restores this to a value of 1.
See bug report for details.
Testing:
- new regression test
- tiers 1-3
Thanks,
David
-
Commit messages:
- 8274349:
On Tue, 21 Sep 2021 13:10:57 GMT, Roger Riggs wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2217:
>>
>>> 2215: // A unique (59s) time is needed to avoid killing
>>> other sleep processes.
>>> 2216: final String[] cmd = { "/bin/bash", "-c",
>>>
On Tue, 21 Sep 2021 17:52:31 GMT, Brian Burkhalter wrote:
>> We can either revert this part of the change or rephrase it. Mind you,
>> rephrasing might prove tricky because of non-local changes it might
>> introduce. There's one more occurrence of "wrapped exception" in this file:
>>
On Mon, 20 Sep 2021 13:01:29 GMT, Roger Riggs wrote:
>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified
>> unexpected messages from a child Java VM
>> as the cause of the test failure. Attempts to control the output of the
>> child VM have failed, the VM is
On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}.
>>
>> Caveats:
>> - I excluded `applications` from `hotspot:tier4`,
On Wed, 15 Sep 2021 22:36:14 GMT, Roger Riggs wrote:
>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2452:
>>
>>> 2450:
>>> 2451: if (p.waitFor(10, TimeUnit.MILLISECONDS)) {
>>> 2452: System.out.println("WaitFor didn't wait long enough:
>>> " +
On Fri, 3 Sep 2021 14:25:53 GMT, Roger Riggs wrote:
>> The intermittent test in java/lang/ProcessBuilder/Basic.java has identified
>> unexpected messages from a child Java VM
>> as the cause of the test failure. Attempts to control the output of the
>> child VM have failed, the VM is
On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote:
> Happens with Zero tests:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
>
> java.lang.NullPointerException: Cannot invoke
>
On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote:
> This currently manifests if you run Zero with compiler/codecache/cli tests
> (part of tier1):
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/cli/
>
> STDERR:
> java.lang.RuntimeException:
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and "custom" variants to be handled
>
On Tue, 14 Sep 2021 15:49:36 GMT, Aleksey Shipilev wrote:
>> It isn't the "formal governance" I'm concerned about, more about the folk
>> who use/rely on Zero being the ones to evaluate the impact of a change like
>> this. People, like myself, who do not use Zero in any way cannot evaluate
>>
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
This pull request has now been integrated.
Changeset: c54a918a
Author:David Holmes
URL:
https://git.openjdk.java.ne
On Tue, 14 Sep 2021 00:15:31 GMT, David Holmes wrote:
> Please review this trivial fix to add the missing comma.
>
> Thanks,
> David
Thanks Paul and Ian!
-
PR: https://git.openjdk.java.net/jdk/pull/5504
Please review this trivial fix to add the missing comma.
Thanks,
David
-
Commit messages:
- 8273691: Missing comma after 2021 in GraphemeTestAccessor.java copyright
notice
Changes: https://git.openjdk.java.net/jdk/pull/5504/files
Webrev:
On 11/09/2021 5:24 am, kabutz wrote:
On Fri, 10 Sep 2021 14:08:05 GMT, Claes Redestad wrote:
This looks good. @cl4es might want to confirm that change was not intentional.
Completely unintentional, and perplexing since it's not a simple copy-paste
error..
The thread priorities in Java
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
>
On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote:
>> Currently, the build system defaults the libjvm.so location to "server".
>> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
>> need to see if moving the libjvm.so to a proper location breaks anything.
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper location breaks anything.
>
>
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote:
>> JDK-8179317 rewritten runtime shell tests to Java. There is a little
>> omission in VM variant selection, which makes Zero fail some of the tier1
>> tests, like:
>>
>>
>> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>>
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they
>> take
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Marked as reviewed by dholmes (Reviewer).
On Tue, 7 Sep 2021 23:19:37 GMT, Sandhya Viswanathan
wrote:
>> Hi Sandhya,
>>
>> You must not change another company's copyright line, so "All rights
>> reserved" needs to be removed again.
>>
>> Thanks,
>> David
>
> @dholmes-ora I am from Intel so editing the Intel copyright line should be
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
Hi Sandhya,
You must not change another
pull request incrementally with one additional
commit since the last revision:
Drop applications and fix the comment
_Mailing list message from [David Holmes](mailto:david.hol...@oracle.com) on
[hotspot-dev](mailto:hotspot-...@mail.openjdk.java.net):_
On 7/09/2021 1:17 am, Aleksey Sh
On 7/09/2021 1:17 am, Aleksey Shipilev wrote:
@dholmes-ora: Generally speaking, all `tierX` definitions are rather arbitrary, as there
seem to be nothing intrinsic about the tests to be in a particular tier. In other words,
what `tierX` consists of is a matter of agreement. I'd say
On Mon, 6 Sep 2021 06:45:07 GMT, q2q-2q2
wrote:
>> Shortcut String equality checks by checking equality of the value array
>
> q2q-2q2 has updated the pull request incrementally with one additional commit
> since the last revision:
>
> JDK-8272192 Shortcut String equality checks by checking
On Mon, 6 Sep 2021 06:41:38 GMT, q2q-2q2
wrote:
>> src/java.base/share/classes/java/lang/String.java line 1964:
>>
>>> 1962: public boolean equalsIgnoreCase(String anotherString) {
>>> 1963: if (anotherString != null) {
>>> 1964: return false;
>>
>> This one is
On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote:
> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
> @iignatev suggested to create tier4 groups that capture all tests not in
> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they
> take 10+
On 3/09/2021 12:45 am, Roger Riggs wrote:
On Sat, 28 Aug 2021 02:34:48 GMT, Roger Riggs wrote:
The intermittent test in java/lang/ProcessBuilder/Basic.java has identified
unexpected messages from a child Java VM
as the cause of the test failure. Attempts to control the output of the child
101 - 200 of 2723 matches
Mail list logo
