On Tue, 27 Oct 2020 06:35:33 GMT, Aleksey Shipilev wrote:
>>> > My rationale is simple: I am playing the whack-a-mole against the ongoing
>>> > x86_32 regressions here
>>>
>>> Would it be possible that we add a Travis hook so that commits get tested
>>> once before they are merged?
>>
>> Mayb
On Tue, 27 Oct 2020 06:35:33 GMT, Aleksey Shipilev wrote:
>>> > My rationale is simple: I am playing the whack-a-mole against the ongoing
>>> > x86_32 regressions here
>>>
>>> Would it be possible that we add a Travis hook so that commits get tested
>>> once before they are merged?
>>
>> Mayb
On Tue, 27 Oct 2020 08:53:29 GMT, Aleksey Shipilev wrote:
>> Let me coop this PR to rename x32 -> x86, among other cosmetic changes. Once
>> #830 lands, I'll update x32 -> x86 in those new blocks as well. This way, we
>> can have best of both worlds: x86_32 would start testing, and we would do
On Tue, 27 Oct 2020 09:22:39 GMT, Magnus Ihse Bursie wrote:
> Do you mean that you consider #505 and #548 dependent on this bug? If so, I
> think you misunderstand the purpose of the Github submit testing hook. You
> can -- and should! -- still do proper testing just as you did before the
> mi
On Sun, 18 Oct 2020 09:07:17 GMT, Magnus Ihse Bursie wrote:
>> Bernhard Urban-Forster has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - uppercase suffix
>> - add assert
>
> Build changes look fine now.
@theRealAph does the PR look okay
On Tue, 27 Oct 2020 09:38:41 GMT, Aleksey Shipilev wrote:
> > Do you mean that you consider #505 and #548 dependent on this bug? If so, I
> > think you misunderstand the purpose of the Github submit testing hook. You
> > can -- and should! -- still do proper testing just as you did before the
On Tue, 27 Oct 2020 09:38:41 GMT, Aleksey Shipilev wrote:
>> Do you mean that you consider #505 and #548 dependent on this bug? If so, I
>> think you misunderstand the purpose of the Github submit testing hook. You
>> can -- and should! -- still do proper testing just as you did before the
>>
On Tue, 27 Oct 2020 09:38:41 GMT, Aleksey Shipilev wrote:
>> Do you mean that you consider #505 and #548 dependent on this bug? If so, I
>> think you misunderstand the purpose of the Github submit testing hook. You
>> can -- and should! -- still do proper testing just as you did before the
>>
> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
> platform, because that finds problems with runtime tests and internal
> asserts. Those problems do not show up during the plain build. Again, while
> x86_32 might not be widely deployed by itself, but 32/64 bit cleanlin
On Tue, 27 Oct 2020 10:39:29 GMT, Aleksey Shipilev wrote:
>> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
>> platform, because that finds problems with runtime tests and internal
>> asserts. Those problems do not show up during the plain build. Again, while
>> x86_3
On Tue, 27 Oct 2020 10:36:08 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Rename "x32" -> "x86" in the test steps
>> - Merge branch 'JDK-8255412-add-x32-default' into JDK-8255305-
On Tue, 27 Oct 2020 10:42:36 GMT, Aleksey Shipilev wrote:
>> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
>> platform, because that finds problems with runtime tests and internal
>> asserts. Those problems do not show up during the plain build. Again, while
>> x86_3
Hi lx,
the need to add --enable-preview is known, and it's a bug introduced a
couple of months ago thanks to a suggestion I did (without realizing
that compiling one micro with --enable-preview would poison all of
them..). This issue is tracked by a few bugs, see
https://bugs.openjdk.java.net/bro
Man pages should be placed in the same module as the corresponding executable.
For some reason, this was done incorrectly for jfr, where the executable is
provided by jdk.jfr, but the man page was in java.base.
-
Commit messages:
- 8252113: Move jfr man page into jfr module
Change
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Tue, 27 Oct 2020 12:50:39 GMT, Magnus Ihse Bursie wrote:
> Man pages should be placed in the same module as the corresponding
> executable. For some reason, this was done incorrectly for jfr, where the
> executable is provided by jdk.jfr, but the man page was in java.base.
Marked as reviewe
Hi,
I follow the instruction on
https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/testing.html#microbenchmarks
to run a new microbenchmark.
I got error message as follows.
java.lang.UnsupportedClassVersionError: Preview features are not enabled for
org/openjdk/bench/
On Tue, 27 Oct 2020 10:49:12 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Rename "x32" -> "x86" in the test steps
>> - Merge branch 'JDK-8255412-add-x32-default' into JDK-8255305-
On Tue, 27 Oct 2020 13:22:49 GMT, Aleksey Shipilev wrote:
>> Looks good to me now. Thank you!
>
> Testing is still clean apart for missing #833 change. Okay to push then?
I think you should wait for the problem list. Otherwise you'll introduce
intentional test breakage in GH actions.
-
On Mon, 26 Oct 2020 18:45:31 GMT, Aleksey Shipilev wrote:
> John Paul Adrian Glaubitz mentions "x32" is actually the designation for
> "x86_64 with 32-bit pointers". Let's rename "Linux x32" to "Linux x86". I
> also realized that JDK-8254282 missed "Linux x32" for the platform selection.
> Whi
On Tue, 27 Oct 2020 13:32:41 GMT, Magnus Ihse Bursie wrote:
>> Testing is still clean apart for missing #833 change. Okay to push then?
>
> I think you should wait for the problem list. Otherwise you'll introduce
> intentional test breakage in GH actions.
#833 is now merged, I am pushing this t
On Tue, 27 Oct 2020 12:50:39 GMT, Magnus Ihse Bursie wrote:
> Man pages should be placed in the same module as the corresponding
> executable. For some reason, this was done incorrectly for jfr, where the
> executable is provided by jdk.jfr, but the man page was in java.base.
This pull request
On Fri, 23 Oct 2020 10:04:49 GMT, Aleksey Shipilev wrote:
> Following JDK-8254282, it seems useful to also run tier1 tests on 32-bit
> platform, because that finds problems with runtime tests and internal
> asserts. Those problems do not show up during the plain build. Again, while
> x86_32 mi
On Thu, 15 Oct 2020 18:35:30 GMT, Bernhard Urban-Forster
wrote:
>> I organized this PR so that each commit contains the warning emitted by MSVC
>> as commit message and its relevant fix.
>>
>> Verified on
>> * Linux+ARM64: `{hotspot,jdk,langtools}:tier1`, no failures.
>> * Windows+ARM64: `{hot
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first,
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore
wrote:
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first,
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Fri, 23 Oct 2020 17:22:33 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removing unnecessary cast.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecut
On Tue, 27 Oct 2020 14:04:04 GMT, Andrew Haley wrote:
>> Bernhard Urban-Forster has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - uppercase suffix
>> - add assert
>
> Marked as reviewed by aph (Reviewer).
Thank you for the reviews, Mag
> This patch contains the changes associated with the third incubation round of
> the foreign memory access API incubation (see JEP 393 [1]). This iteration
> focus on improving the usability of the API in 3 main ways:
>
> * first, by providing a way to obtain truly *shared* segments, which can
On Sat, 24 Oct 2020 22:22:56 GMT, Peter Levart wrote:
>> Reference instances should not be leaked and so I don't see very common that
>> caller of `Reference::get` does not know the referent's type. It also
>> depends on the `refersTo` check against `null` vs an object. Any known use
>> cas
On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote:
>> Finally returning to this review that was started in April 2020. I've
>> recast it as a github PR. I think the security concern raised by Gil
>> has been adequately answered.
>> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A
33 matches
Mail list logo
