Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v5]

[Yumin Qi]

> This patch is reorganized after 8252725, which is separated from this patch 
> to refactor jlink glugin code. The previous
> webrev with hg can be found at: 
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 
> integrated, the
> regeneration of holder classes is simply to call the new added 
> GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request with a new target base due to a merge or 
a rebase. The pull request now contains
14 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into jdk-8247536
 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - Merge branch 'master' into jdk-8247536
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - Merge remote-tracking branch 'upstream/master' into jdk-8247536
 - Merge remote-tracking branch 'upstream/master' into jdk-8247536
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b159e4ed...01b229cc

-

Changes: https://git.openjdk.java.net/jdk/pull/193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=193=04
  Stats: 464 lines in 21 files changed: 440 ins; 13 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3]

[Ioi Lam]

On Fri, 25 Sep 2020 21:19:39 GMT, Yumin Qi  wrote:

>> This patch is reorganized after 8252725, which is separated from this patch 
>> to refactor jlink glugin code. The previous
>> webrev with hg can be found at: 
>> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 
>> integrated, the
>> regeneration of holder classes is simply to call the new added 
>> GenerateJLIClassesHelper.cdsGenerateHolderClasses
>> function.  Tests: tier1-4
>
> Yumin Qi has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8247536: Support for pre-generated java.lang.invoke classes in CDS static 
> archive

Changes requested by iklam (Reviewer).

test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 32:

> 30:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 31:  * @compile ClassListFormatBase.java test-classes/Hello.java
> 32:  * @run driver DumpClassListWithLF

The `@compile` line can be removed to speed up the test execution. You can add 
this:

@library /test/lib /test/hotspot/jtreg/runtime/cds/appcds/test-classes

and also change the code below

appJar, classlist(
-"Hello",
+Hello.class.getName(),

(There's no need for `/test/hotspot/jtreg/runtime/cds/appcds` in `@library` 
because that's the current directory of
this test).

test/hotspot/jtreg/runtime/cds/appcds/DumpClassListWithLF.java line 53:

> 51: "Hello",
> 52: "@lambda-form-invoker [LF_RESOLVE] 
> java.lang.invoke.DirectMethodHandle$Holder invokeStatic L7_L
> (success)", 53: "@lambda-form-invoker [LF_RESOLVE] 
> java.lang.invoke.DirectMethodHandle$Holder
> invokeStatic LL_I (success)"),

I think the `(success)` part should not be included in the classlist. The 
classlist is the public interface. It should
be concise and include only the necessary information.

@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder 
invokeStatic L7_L
@lambda-form-invoker [LF_RESOLVE] java.lang.invoke.DirectMethodHandle$Holder 
invokeStatic LL_I

test/hotspot/jtreg/runtime/cds/appcds/customLoader/ProhibitedPackageNamesTest.java
 line 31:

> 29:  * @requires vm.cds.custom.loaders
> 30:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 31:  * @compile ../ClassListFormatBase.java ../test-classes/Hello.java 
> test-classes/InProhibitedPkg.java

Similar comment for avoiding `@compile`.  `@compile` has been mis-used by older 
CDS tests. We should avoid using it,
and should remove it when we are touching the old tests.

src/hotspot/share/classfile/systemDictionary.cpp line 1864:

> 1862:
> 1863: // Used for assertions and verification, also used from 
> LambdaFormInvokers::reload_class
> 1864: // to get original class which has already been loaded.

Is the above comment change still needed?

-

PR: https://git.openjdk.java.net/jdk/pull/193

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v4]

[Yumin Qi]

> This patch is reorganized after 8252725, which is separated from this patch 
> to refactor jlink glugin code. The previous
> webrev with hg can be found at: 
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 
> integrated, the
> regeneration of holder classes is simply to call the new added 
> GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request incrementally with one additional commit 
since the last revision:

  8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/b1955272..4148e7d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=193=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=193=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v3]

[Yumin Qi]

> This patch is reorganized after 8252725, which is separated from this patch 
> to refactor jlink glugin code. The previous
> webrev with hg can be found at: 
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 
> integrated, the
> regeneration of holder classes is simply to call the new added 
> GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request incrementally with one additional commit 
since the last revision:

  8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/193/files
  - new: https://git.openjdk.java.net/jdk/pull/193/files/f45f364d..b1955272

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=193=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=193=01-02

  Stats: 88 lines in 15 files changed: 57 ins; 15 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive [v2]

[Yumin Qi]

> This patch is reorganized after 8252725, which is separated from this patch 
> to refactor jlink glugin code. The previous
> webrev with hg can be found at: 
> http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-05. With 8252725 
> integrated, the
> regeneration of holder classes is simply to call the new added 
> GenerateJLIClassesHelper.cdsGenerateHolderClasses
> function.  Tests: tier1-4

Yumin Qi has updated the pull request with a new target base due to a merge or 
a rebase. The pull request now contains
11 commits:

 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - Merge branch 'master' into jdk-8247536
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - 8247536: Support for pre-generated java.lang.invoke classes in CDS static 
archive
 - Merge remote-tracking branch 'upstream/master' into jdk-8247536
 - Merge remote-tracking branch 'upstream/master' into jdk-8247536
 - Merge remote-tracking branch 'origin/jdk-8252689'
 - 8252689: Classes are loaded from jrt:/java.base even when CDS is used
 - 8252689: Classes are loaded from jrt:/java.base even when CDS is used
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/8b85c3a6...f45f364d

-

Changes: https://git.openjdk.java.net/jdk/pull/193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=193=01
  Stats: 425 lines in 19 files changed: 399 ins; 13 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/193/head:pull/193

PR: https://git.openjdk.java.net/jdk/pull/193

RFR: 8253660: Need better error report when artifact resolution fails in AotCompiler.java

[Erik Joelsson]

In AotCompiler.java, if artifact resolution fails, we have no way of diagnosing 
the error. This patch improves the
default toString() of ArtifactResolverException to automatically include the 
toString() method of the root cause. It
also adds stack trace printing specifically in AotCompiler.java.

I also found a similar issue in PKCS11Test, and fixed it by adding the 
ArtifactResolverException there as cause for the
RuntimeException being thrown. This causes the stack trace to be printed on 
failure.

I looked through all other uses of ArtifactResolver, but they are handling the 
exception in a way that already prints
the stack trace.

-

Commit messages:
 - Add cause to RuntimeException in PKCS11Test
 - Include root cause message in ArtifactResolverException by default. Print 
stack trace in AotCotCompiler.

Changes: https://git.openjdk.java.net/jdk/pull/368/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=368=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253660
  Stats: 14 lines in 3 files changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/368/head:pull/368

PR: https://git.openjdk.java.net/jdk/pull/368

Re: cve-2014-3566 cve-2014-6593 in OPEN JDK 8

[David Holmes]

On 25/09/2020 10:28 pm, Moshe Zuisman wrote:
Hi David. Do this Vulnerability group have some their own forum, mail 
list or other place - they can be contacted?


I assumed they did have but it seems not :(

https://openjdk.java.net/groups/vulnerability/

The only mailing list they have that you can post to is for 
vulnerability reports.


I suspect you have to pick an OpenJDK distributor and then ask them 
about this, rather than trying to find out generically what "version of 
OpenJDK" contains a given fix. I'm pretty sure that we don't record CVE 
details when such fixes get integrated.


David
-

пт, 25 сент. 2020 г. в 13:58, David Holmes >:


Hi Moshe,

On 25/09/2020 8:23 pm, Moshe Zuisman wrote:
 > Hi.
 > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
 > starting from which build.

This is not something that build-dev can help you with.

The best people to contact for this would be the Vulnerability group
that Alan referred to.

There is historical information available for Oracle JDK [1] but I
don't
know how to map that to OpenJDK for certain.

Cheers,
David
-

[1] To go that far back you'd need to check:

https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html

for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566
it is:

https://www.oracle.com/security-alerts/cpujul2017.html

which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not
sure whether than means it is fixed in 8u131 or whether 8u131 is still
affected and the fix is in the next CPU release.)

 > Alan Bateman pointed me to
 > https://openjdk.java.net/groups/vulnerability/advisories/. But it
contains
 > only a list of fixed vulnerabilities, that were reported at
2019-2020 years.
 > I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html
 > that Open JDK 8 for Oracle Linux 6 already contained fix for
cve-2014-3566
 > for example.
 > But - is there some way, I can be sure that this was included in the
 > general code base of Open JDK(and not some special branch -
ORACLE manages
 > for their systems), and starting from which build this fix was
included?
 >

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5]

[Erik Joelsson]

On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg  wrote:

>> A few days ago I posted an initial version of the necessary configuration 
>> required to run pre-submit build and tests
>> for JDK main-line contributions using GitHub Actions [2] and the free tier 
>> [3] available to everyone working with open
>> source repositories. I've incorporated the feedback into an updated version 
>> that I believe is ready to be integrated.
>> If this is integrated into the `master` branch, future branches created and 
>> updated in personal forks will build and
>> run the basic tier 1 tests as described in this configuration, on Linux, 
>> Windows and macOS (all on x64). It's of course
>> possible for any contributor to opt out fully or partially of these 
>> automatic runs in a few different ways.  To opt out
>> completely, a contributor can simply disable GitHub Actions on their 
>> personal fork, and no further jobs will be
>> executed. Another option is to add a repository secret [4] with the name 
>> `JDK_SUBMIT_FILTER` set to any value. If this
>> is set, only branches prefixed with `submit/` will be subject to automatic 
>> build and test. This can also be further
>> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a 
>> value such as `Linux x64, Windows x64` to
>> limit automatic build and test to these two platforms. It will still be 
>> possible to run the tests on any branch and/or
>> platform by manually triggering the workflow.  To see what this looks like 
>> in practice, an example run can be found
>> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that 
>> there is currently a failing test on Windows
>> which is tracked by JDK-8249095, which should probably be resolved before 
>> this change is integrated).  Best regards,
>> Robin  [1] 
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html 
>> [2]
>> https://github.com/features/actions [3]
>> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
>>  [4]
>> https://docs.github.com/en/actions/reference/encrypted-secrets
>
> Robin Westberg has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Avoid persisting transient artifacts, combine all test results into a final 
> bundle

Marked as reviewed by erikj (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5]

[Erik Helin]

On Fri, 25 Sep 2020 13:10:01 GMT, Robin Westberg  wrote:

>> A few days ago I posted an initial version of the necessary configuration 
>> required to run pre-submit build and tests
>> for JDK main-line contributions using GitHub Actions [2] and the free tier 
>> [3] available to everyone working with open
>> source repositories. I've incorporated the feedback into an updated version 
>> that I believe is ready to be integrated.
>> If this is integrated into the `master` branch, future branches created and 
>> updated in personal forks will build and
>> run the basic tier 1 tests as described in this configuration, on Linux, 
>> Windows and macOS (all on x64). It's of course
>> possible for any contributor to opt out fully or partially of these 
>> automatic runs in a few different ways.  To opt out
>> completely, a contributor can simply disable GitHub Actions on their 
>> personal fork, and no further jobs will be
>> executed. Another option is to add a repository secret [4] with the name 
>> `JDK_SUBMIT_FILTER` set to any value. If this
>> is set, only branches prefixed with `submit/` will be subject to automatic 
>> build and test. This can also be further
>> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a 
>> value such as `Linux x64, Windows x64` to
>> limit automatic build and test to these two platforms. It will still be 
>> possible to run the tests on any branch and/or
>> platform by manually triggering the workflow.  To see what this looks like 
>> in practice, an example run can be found
>> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that 
>> there is currently a failing test on Windows
>> which is tracked by JDK-8249095, which should probably be resolved before 
>> this change is integrated).  Best regards,
>> Robin  [1] 
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html 
>> [2]
>> https://github.com/features/actions [3]
>> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
>>  [4]
>> https://docs.github.com/en/actions/reference/encrypted-secrets
>
> Robin Westberg has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Avoid persisting transient artifacts, combine all test results into a final 
> bundle

Looks good to me, awesome work @rwestberg!

-

Marked as reviewed by ehelin (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8253624: gtest fails when run from make with read-only source directory

[Erik Joelsson]

On Fri, 25 Sep 2020 07:45:34 GMT, Nick Gasson  wrote:

> In an out-of-tree build where the source code is in a read-only location
> several gtests such as LogFileOutput.invalid_file_test_vm will fail
> because they write files to the current working directory.
> 
>   [ RUN ] LogFileOutput.invalid_file_test_vm
>   # To suppress the following error report, specify this argument
>   # after -XX: or in .hotspotrc: SuppressErrorAt=/logTestUtils.inline.hpp:65
>   assert failed: failed to create directory tmplogdir
>   #
>   # A fatal error has been detected by the Java Runtime Environment:
>   #
>   # Internal Error 
> (/mnt/nicgas01-pc/jdk/test/hotspot/gtest/logging/logTestUtils.inline.hpp:65), 
> pid=51470, tid=51470
>   # assert(!failed) failed: failed to create directory tmplogdir
> 
> Run the gtest launcher with the working directory set to the test
> support directory which we know is writable.

That's a nice fix, thanks!

-

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/354

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions

[Robin Westberg]

On Wed, 23 Sep 2020 17:55:23 GMT, Robin Westberg  wrote:

>> The version-numbers file (which is also a shared properties style file) is 
>> not using quotes for values, which is fine
>> as long as there are no spaces. I believe if you read it as a properties 
>> file, you need to strip the quotes if you have
>> them. I prefer if version-numbers and test-dependencies using the same 
>> format.  Otherwise this looks good to me!
>
> Sounds reasonable, didn't notice that discrepancy! Fixed in the latest commit.

After some feedback on the jdk-dev mailing list (thanks @jaikiran!) I took a 
second look at removing artifacts that are
only created for passing between the build and test steps. Turns out that there 
is an API for this (it's still in
preview, but seems to work fine) that can be used for this. When this API is 
finalized we can update that part, but
it's not a deal-breaker even if it should change, as the test runs will still 
complete successfully. With this API
available, it's also possible to publish a single artifact containing all test 
results, regardless of outcome.

-

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8253424: Add support for running pre-submit testing using GitHub Actions [v5]

[Robin Westberg]

> A few days ago I posted an initial version of the necessary configuration 
> required to run pre-submit build and tests
> for JDK main-line contributions using GitHub Actions [2] and the free tier 
> [3] available to everyone working with open
> source repositories. I've incorporated the feedback into an updated version 
> that I believe is ready to be integrated.
> If this is integrated into the `master` branch, future branches created and 
> updated in personal forks will build and
> run the basic tier 1 tests as described in this configuration, on Linux, 
> Windows and macOS (all on x64). It's of course
> possible for any contributor to opt out fully or partially of these automatic 
> runs in a few different ways.  To opt out
> completely, a contributor can simply disable GitHub Actions on their personal 
> fork, and no further jobs will be
> executed. Another option is to add a repository secret [4] with the name 
> `JDK_SUBMIT_FILTER` set to any value. If this
> is set, only branches prefixed with `submit/` will be subject to automatic 
> build and test. This can also be further
> refined by adding a repository secret named `JDK_SUBMIT_PLATFORMS` with a 
> value such as `Linux x64, Windows x64` to
> limit automatic build and test to these two platforms. It will still be 
> possible to run the tests on any branch and/or
> platform by manually triggering the workflow.  To see what this looks like in 
> practice, an example run can be found
> here: https://github.com/rwestberg/jdk/actions/runs/265131985 (note that 
> there is currently a failing test on Windows
> which is tracked by JDK-8249095, which should probably be resolved before 
> this change is integrated).  Best regards,
> Robin  [1] 
> https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004736.html [2]
> https://github.com/features/actions [3]
> https://docs.github.com/en/actions/getting-started-with-github-actions/about-github-actions#usage-limits
>  [4]
> https://docs.github.com/en/actions/reference/encrypted-secrets

Robin Westberg has updated the pull request incrementally with one additional 
commit since the last revision:

  Avoid persisting transient artifacts, combine all test results into a final 
bundle

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/284/files
  - new: https://git.openjdk.java.net/jdk/pull/284/files/de5074fe..441a18b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=284=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=284=03-04

  Stats: 92 lines in 1 file changed: 64 ins; 6 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/284.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/284/head:pull/284

PR: https://git.openjdk.java.net/jdk/pull/284

Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v7]

[Andrew Haley]

On Thu, 24 Sep 2020 15:15:45 GMT, Monica Beckwith  wrote:

>> This is a continuation of 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>>  
>> Changes since then:
>> * We've improved the write barrier as suggested by Andrew [1]
>> * The define-guards around R18 have been changed to `R18_RESERVED`. This 
>> will be enabled for Windows only for now but
>>   will be required for the upcoming macOS+Aarch64 [2] port as well.
>> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov 
>> in our PR for now and built the
>>   Windows-specific CPU feature detection on top of it.
>> 
>> [1] 
>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
>> [2] https://openjdk.java.net/jeps/8251280
>
> Monica Beckwith has updated the pull request incrementally with two 
> additional commits since the last revision:
> 
>  - os_windows: remove duplicated UMA handling
>  - test_safefetch{32,N} works fine on win+aarch64

Marked as reviewed by aph (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/212

Re: cve-2014-3566 cve-2014-6593 in OPEN JDK 8

[Moshe Zuisman]

Hi David. Do this  Vulnerability group have some their own forum, mail list
or other place - they can be contacted?

пт, 25 сент. 2020 г. в 13:58, David Holmes :

> Hi Moshe,
>
> On 25/09/2020 8:23 pm, Moshe Zuisman wrote:
> > Hi.
> > I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
> > starting from which build.
>
> This is not something that build-dev can help you with.
>
> The best people to contact for this would be the Vulnerability group
> that Alan referred to.
>
> There is historical information available for Oracle JDK [1] but I don't
> know how to map that to OpenJDK for certain.
>
> Cheers,
> David
> -
>
> [1] To go that far back you'd need to check:
>
> https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html
>
> for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566
> it is:
>
> https://www.oracle.com/security-alerts/cpujul2017.html
>
> which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not
> sure whether than means it is fixed in 8u131 or whether 8u131 is still
> affected and the fix is in the next CPU release.)
>
> > Alan Bateman pointed me to
> > https://openjdk.java.net/groups/vulnerability/advisories/. But it
> contains
> > only a list of fixed vulnerabilities, that were reported at 2019-2020
> years.
> > I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html
> > that Open JDK 8 for Oracle Linux 6 already contained fix for
> cve-2014-3566
> > for example.
> > But - is there some way, I can be sure that this was included in the
> > general code base of Open JDK(and not some special branch - ORACLE
> manages
> > for their systems), and starting from which build this fix was included?
> >
>

Re: cve-2014-3566 cve-2014-6593 in OPEN JDK 8

[David Holmes]

Hi Moshe,

On 25/09/2020 8:23 pm, Moshe Zuisman wrote:

Hi.
I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
starting from which build.


This is not something that build-dev can help you with.

The best people to contact for this would be the Vulnerability group 
that Alan referred to.


There is historical information available for Oracle JDK [1] but I don't 
know how to map that to OpenJDK for certain.


Cheers,
David
-

[1] To go that far back you'd need to check:

https://www.oracle.com/security-alerts/public-vuln-to-advisory-mapping.html

for the CVE and find the corresponding CPU link. E.g. for cve-2014-3566 
it is:


https://www.oracle.com/security-alerts/cpujul2017.html

which applies to Oracle Java SE, versions 6u151, 7u141, 8u131. (I'm not 
sure whether than means it is fixed in 8u131 or whether 8u131 is still 
affected and the fix is in the next CPU release.)



Alan Bateman pointed me to
https://openjdk.java.net/groups/vulnerability/advisories/. But it contains
only a list of fixed vulnerabilities, that were reported at 2019-2020 years.
I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html
that Open JDK 8 for Oracle Linux 6 already contained fix for cve-2014-3566
for example.
But - is there some way, I can be sure that this was included in the
general code base of Open JDK(and not some special branch - ORACLE manages
for their systems), and starting from which build this fix was included?

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Kim Barrett]

> On Sep 25, 2020, at 6:22 AM, Lutz Schmidt  wrote:
> 
> On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett  wrote:
> 
> Another note, actually, it's more like a question:
> Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* 
> buf, int length)? To my understanding,
> "buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is 
> that a good idea? "locs_buf" points into
> the stack. This pointer becomes invalid at the end of the "locs_buf" scope. 
> Did I get something wrong here?

It’s “odd” but I think it’s more or less okay.  Here and in other uses we seem 
to be allocating
dynamically scoped storage for temporary use by the CodeBuffer.  I think a more 
normal
formulation might be to allocate the buffer, then pass it to the CodeBuffer 
constructor as a
non-transfer of ownership.  But I haven’t looked at all the places where this 
is used, and that’s
perhaps out of scope for the problem at hand.

> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/348

cve-2014-3566 cve-2014-6593 in OPEN JDK 8

[Moshe Zuisman]

Hi.
I am trying to figure out if cve-2014-3566 cve-2014-6593 nad if yes -
starting from which build.
Alan Bateman pointed me to
https://openjdk.java.net/groups/vulnerability/advisories/. But it contains
only a list of fixed vulnerabilities, that were reported at 2019-2020 years.
I have found at https://linux.oracle.com/errata/ELSA-2015-0069.html
that Open JDK 8 for Oracle Linux 6 already contained fix for cve-2014-3566
for example.
But - is there some way, I can be sure that this was included in the
general code base of Open JDK(and not some special branch - ORACLE manages
for their systems), and starting from which build this fix was included?

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Lutz Schmidt]

On Fri, 25 Sep 2020 05:46:08 GMT, Kim Barrett  wrote:

>> Please review this small patch to enable the OSX build using Xcode 12.0.
>> 
>> Thanks,
>> Paul
>
> No, don't do this.  In the original, double is used to obtain the desired
> alignmnent.  Changing the element type to short reduces the alignment
> requirement for the variable.  initialize_shared_locs will then adjust the
> alignment, potentially shrinking the effective array size.  So this is a
> real change that I think shouldn't be made.
> 
> I think changing the declaration for locs_buf to any of the following gives
> equivalent behavior to the current code. I don't know whether any of them
> will trigger the new clang warning though. I don't have access to that
> version right now, and the documentation for the warning is useless (like so
> much of clang's warning options documentation).
> 
> (1) alignas(double) char locs_buf[20 * sizeof(double)];
> (but alignas is not yet in the "permitted features" list in the Style Guide:
> https://bugs.openjdk.java.net/browse/JDK-8252584)
> 
> (2) union { char locs_buf[20 * sizeof(double)]; double align; };
> 
> (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf;
> and change (relocInfo*)locs_buf => (relocInfo*)_buf
> and #include 
> This has the benefit of being explicit that we're just stack allocating a
> block of storage.
> 
> I'll make a wild guess that (1) and (2) will still warn, though char arrays
> are somewhat special in the language so maybe they won't.  I'm pretty sure
> (3) should do the trick.

I checked Kim Barrett's proposals (1) and (2) on my machine (MacOS 10.15, Xcode 
12.0). Both proposals make the warning
go away.

Another note, actually, it's more like a question:
Has anyone had an eye on what happens in initialize_shared_locs(relocInfo* buf, 
int length)? To my understanding,
"buf", which is passed in as "locs_buf", is stored into CodeBuffer fields. Is 
that a good idea? "locs_buf" points into
the stack. This pointer becomes invalid at the end of the "locs_buf" scope. Did 
I get something wrong here?

-

PR: https://git.openjdk.java.net/jdk/pull/348

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Kim Barrett]

> On Sep 25, 2020, at 1:49 AM, Kim Barrett  wrote:
> 
> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee  wrote:
> 
>> Please review this small patch to enable the OSX build using Xcode 12.0.
>> 
>> Thanks,
>> Paul
> 
> […]
> 
> I think changing the declaration for locs_buf to any of the following gives
> equivalent behavior to the current code. […]
> 
> […]

Another variant that probably avoids both the warning and avoids any C++14 
features:

(4)  union { char data[20 * sizeof(double)]; double align; } locs_buf;
and change (relocInfo*)locs_buf => (relocInfo*)_buf.

> -
> 
> Changes requested by kbarrett (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/348

RFR: 8253624: gtest fails when run from make with read-only source directory

[Nick Gasson]

In an out-of-tree build where the source code is in a read-only location
several gtests such as LogFileOutput.invalid_file_test_vm will fail
because they write files to the current working directory.

  [ RUN ] LogFileOutput.invalid_file_test_vm
  # To suppress the following error report, specify this argument
  # after -XX: or in .hotspotrc: SuppressErrorAt=/logTestUtils.inline.hpp:65
  assert failed: failed to create directory tmplogdir
  #
  # A fatal error has been detected by the Java Runtime Environment:
  #
  # Internal Error 
(/mnt/nicgas01-pc/jdk/test/hotspot/gtest/logging/logTestUtils.inline.hpp:65), 
pid=51470, tid=51470
  # assert(!failed) failed: failed to create directory tmplogdir

Run the gtest launcher with the working directory set to the test
support directory which we know is writable.

-

Commit messages:
 - 8253624: gtest fails when run from make with read-only source directory

Changes: https://git.openjdk.java.net/jdk/pull/354/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=354=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253624
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/354.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/354/head:pull/354

PR: https://git.openjdk.java.net/jdk/pull/354

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Kim Barrett]

> On Sep 25, 2020, at 1:49 AM, Kim Barrett  wrote:
> 
> On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee  wrote:
> 
>> Please review this small patch to enable the OSX build using Xcode 12.0.
>> 
>> Thanks,
>> Paul

[I tried submitting this comment through the github UI and somehow managed to 
lose
all the context in the process.  In case it’s not (eventually) obvious, this is 
about the
change to src/hotspot/share/runtime/sharedRuntime.cpp.  Still figuring out 
github…]

> No, don't do this.  In the original, double is used to obtain the desired
> alignmnent.  Changing the element type to short reduces the alignment
> requirement for the variable.  initialize_shared_locs will then adjust the
> alignment, potentially shrinking the effective array size.  So this is a
> real change that I think shouldn't be made.
> 
> I think changing the declaration for locs_buf to any of the following gives
> equivalent behavior to the current code. I don't know whether any of them
> will trigger the new clang warning though. I don't have access to that
> version right now, and the documentation for the warning is useless (like so
> much of clang's warning options documentation).
> 
> (1) alignas(double) char locs_buf[20 * sizeof(double)];
> (but alignas is not yet in the "permitted features" list in the Style Guide:
> https://bugs.openjdk.java.net/browse/JDK-8252584)
> 
> (2) union { char locs_buf[20 * sizeof(double)]; double align; };
> 
> (3) std::aligned_storage_t<20 * sizeof(double)> locs_buf;
> and change (relocInfo*)locs_buf => (relocInfo*)_buf
> and #include 
> This has the benefit of being explicit that we're just stack allocating a
> block of storage.
> 
> I'll make a wild guess that (1) and (2) will still warn, though char arrays
> are somewhat special in the language so maybe they won't.  I'm pretty sure
> (3) should do the trick.
> 
> -
> 
> Changes requested by kbarrett (Reviewer).
> 
> PR: https://git.openjdk.java.net/jdk/pull/348

Re: RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Kim Barrett]

On Thu, 24 Sep 2020 21:28:01 GMT, Paul Hohensee  wrote:

> Please review this small patch to enable the OSX build using Xcode 12.0.
> 
> Thanks,
> Paul

src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m line 129:

> 127: NSColor* result = nil;
> 128:
> 129: if (colorIndex < ((useAppleColor) ? 
> sun_lwawt_macosx_LWCToolkit_NUM_APPLE_COLORS :
> java_awt_SystemColor_NUM_COLORS)) {

This looks like a plain old bug fix, nothing really to do with the compiler 
upgrade.  The new compiler presumably just
has a new warning that brought attention to the problem.  As such, I don't 
think it belongs in a PR that's about issues
related to the compiler upgrade.  Someone might want to backport just this fix, 
for example.

-

PR: https://git.openjdk.java.net/jdk/pull/348