On 4/12/2020 12:42 am, Daniel D.Daugherty wrote:
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote:
The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and
supported three different Linux signal API's: sigset, signal and sigaction:
https://docs.oracle.com/javase/8/do
Hi Erik,
On 4/12/2020 12:07 am, Erik Joelsson wrote:
On Thu, 3 Dec 2020 04:34:52 GMT, David Holmes wrote:
The signal-chaining facility was introduced in JDK 1.4 nearly 20 years ago and
supported three different Linux signal API's: sigset, signal and sigaction:
https://docs.oracle.com/javase
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Marked as reviewed by mikael (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1531
On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith wrote:
> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
>
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal
> - Revise "value-based class" & apply t
Integration of JEP 390, addressing the following issues:
8252180: [JEP 390] Deprecate wrapper class constructors for removal
8254047: [JEP 390] Revise "value-based class" & apply to wrappers
8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased
8252183: [JEP 390] Add 'lint' warning
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1531
> For the build to work on Windows, we need a unix compatibility layer (known
> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
> build system then needs to adapt various aspect to get the build to work in
> this winenv. Over time, our current solutions (which were nev
When building the test-bundle incrementally, it always gets rebuilt. This is
caused by the prepare-test-image target in TestImage.gmk, where we create a
README file as part of a recipe for a PHONY target. This means that the README
is always rebuilt, which in turn triggers downstream rebuilds. T
On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson wrote:
> We have historically provided -mmacosx-version-min=10.9.0 flags when
> compiling and linking all our native executables and libraries on Macosx.
> That flag seems to have disappeared when linking libjvm. This is sometimes
> causing our ma
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Build changes look good and I'm happy there are so few of them!
-
Marked as reviewed by erikj (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1531
On Tue, 1 Dec 2020 07:38:13 GMT, David Holmes wrote:
>> Start of JDK 17 updates.
>
> Looks good - 99% sym stuff :)
>
> Doesn't look like the hotspot deprecated flag test will need updating this
> time, as no newly deprecated flags marked for obsoletion in 17.
Usual start of release update:
*
Start of JDK 17 updates.
-
Commit messages:
- Update tests.
- Merge branch 'master' into JDK-8257450
- Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
- Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
- JDK-8257450
- JD
On Tue, 1 Dec 2020 07:33:25 GMT, David Holmes wrote:
>> Start of JDK 17 updates.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226:
>
>> 224: REIFIABLE_TYPES_INSTANCEOF(JDK16,
>> Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL),
>> 225:
On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy wrote:
> Start of JDK 17 updates.
Looks good - 99% sym stuff :)
Doesn't look like the hotspot deprecated flag test will need updating this
time, as no newly deprecated flags marked for obsoletion in 17.
src/hotspot/share/opto/type.cpp line 827:
> 82
On Fri, 4 Dec 2020 14:44:49 GMT, Erik Joelsson wrote:
> We have historically provided -mmacosx-version-min=10.9.0 flags when
> compiling and linking all our native executables and libraries on Macosx.
> That flag seems to have disappeared when linking libjvm. This is sometimes
> causing our ma
On Fri, 4 Dec 2020 18:54:32 GMT, Magnus Ihse Bursie wrote:
>> For the build to work on Windows, we need a unix compatibility layer (known
>> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
>> build system then needs to adapt various aspect to get the build to work in
On Fri, 4 Dec 2020 18:26:21 GMT, Jorn Vernee wrote:
>> Do you see any significant difference in build times compared to before the
>> patch?
>
> @erikj79 I don't really see a significant difference in the build time of
> `images` on my machine when comparing before and after the patch (but, as
> For the build to work on Windows, we need a unix compatibility layer (known
> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
> build system then needs to adapt various aspect to get the build to work in
> this winenv. Over time, our current solutions (which were nev
On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson wrote:
>> Ok, after looking at `set -x` output WSL seems to have a problem with the
>> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk
>> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that
>> P
On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson wrote:
>> Ok, after looking at `set -x` output WSL seems to have a problem with the
>> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk
>> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that
>> P
On Fri, 4 Dec 2020 18:07:22 GMT, Magnus Ihse Bursie wrote:
>> Ok, after looking at `set -x` output WSL seems to have a problem with the
>> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk
>> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that
On Fri, 4 Dec 2020 15:57:44 GMT, Jorn Vernee wrote:
>> @magicus Thanks! But, now I get the same error as the GH action:
>> https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
>>
>> Looks like `-a` is not supported in my shell. I can make the error go away
>> locally with:
>>
Greetings,
please help review this enhancement to let JFR sample object allocations by
default.
A description is provided in the JIRA issue.
Thanks
Markus
-
Commit messages:
- defensive initialization check
- Whitespace errors
- JFR Event Throttling
Changes: https://git.openjd
On Fri, 4 Dec 2020 17:34:33 GMT, Erik Joelsson wrote:
>> Ok, after looking at `set -x` output WSL seems to have a problem with the
>> space in the path `/mnt/c/Program Files/Java/jdk-15` e.g. if I move the jdk
>> to `/mnt/h/jdk-15` it works. Might be a missing fixup somewhere? (FWIW, that
>> P
On Fri, 4 Dec 2020 15:57:44 GMT, Jorn Vernee wrote:
>> @magicus Thanks! But, now I get the same error as the GH action:
>> https://github.com/magicus/openjdk-sandbox/runs/1498822974#step:11:80
>>
>> Looks like `-a` is not supported in my shell. I can make the error go away
>> locally with:
>>
On Fri, 4 Dec 2020 14:22:45 GMT, Jorn Vernee wrote:
>> @JornVernee I have now pushed a fix that will make `fixpath import` ignore
>> invalid or unknown paths be ignored. Please try again with it.
>
> @magicus Thanks! But, now I get the same error as the GH action:
> https://github.com/magicus/o
On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson wrote:
>> My understanding of JEPs is that they should be viewed as living documents.
>> In this case, I think it's perfectly valid to update JEP 201 with additional
>> source code layout. Both for this and for the other missing dirs.
>
> Regarding
> For the build to work on Windows, we need a unix compatibility layer (known
> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
> build system then needs to adapt various aspect to get the build to work in
> this winenv. Over time, our current solutions (which were nev
We have historically provided -mmacosx-version-min=10.9.0 flags when compiling
and linking all our native executables and libraries on Macosx. That flag seems
to have disappeared when linking libjvm. This is sometimes causing our macosx
builds to not be able to run on older versions of macosx.
On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie wrote:
>> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin
>> PATH in .bash_profile. If I remove that I get a little further.
>>
>> But the same command fails later on a path with a space in it:
>>
>> fixpath: fail
On Fri, 4 Dec 2020 12:45:57 GMT, Magnus Ihse Bursie wrote:
>> Ok, it seems to have been caused by `usr/local/bin` being added to my Cygwin
>> PATH in .bash_profile. If I remove that I get a little further.
>>
>> But the same command fails later on a path with a space in it:
>>
>> fixpath: fail
On Thu, 3 Dec 2020 22:39:00 GMT, Magnus Ihse Bursie wrote:
>> make/common/JavaCompilation.gmk line 241:
>>
>>> 239:
>>> 240: $$($1_JAVAC_SERVER_CONFIG): $$($1_CONFIG_VARDEPS_FILE)
>>> 241:$(ECHO) portfile=$$($1_JAVAC_PORT_FILE) > $$@
>>
>> Did you consider using WriteFile here?
>
On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson wrote:
>>> And I can certainly move jdwp.spec to java.base instead.
>>
>> If jdwp.spec has to move to the src tree then src/java.se is probably the
>> most suitable home because Java SE specifies JDWP as an optional interface.
>> So nothing to do
On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote:
>> And I can certainly move jdwp.spec to java.base instead. That's the reason I
>> need input on this: All I know is that is definitely not the responsibility
>> of the Build Group to maintain that document, and I made my best guess at
>> wh
On Thu, 3 Dec 2020 23:53:20 GMT, Jorn Vernee wrote:
>> @magicus No, the same problems still remain. I seem to have narrowed down
>> the first error to the `set-vs-env.sh` script; the PATH it extracts for
>> VS_PATH contains `usr\local\bin` for some reason.
>>
>>
>> C:\windows\system32
>> H:\c
> For the build to work on Windows, we need a unix compatibility layer (known
> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
> build system then needs to adapt various aspect to get the build to work in
> this winenv. Over time, our current solutions (which were nev
On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie wrote:
> And I can certainly move jdwp.spec to java.base instead.
If jdwp.spec has to move to the src tree then src/java.se is probably the most
suitable home because Java SE specifies JDWP as an optional interface. So
nothing to do with jav
On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman wrote:
>> To facilitate review, here is a list on how the different directories under
>> make/data has moved.
>>
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsr
On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie wrote:
>> Are you proposing any text or guidelines to be added to JEP 201 as part of
>> this?
>>
>> I think the location of jdwp.spec and its location in the build tree may
>> need to be looked at again. It was convenient to have it in the ma
On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
>
On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote:
> A lot (but not all) of the data in make/data is tied to a specific module.
> For instance, the publicsuffixlist is used by java.base, and fontconfig by
> java.desktop. (A few directories, like mainmanifest, is *actually* used by
> ma
A lot (but not all) of the data in make/data is tied to a specific module. For
instance, the publicsuffixlist is used by java.base, and fontconfig by
java.desktop. (A few directories, like mainmanifest, is *actually* used by make
for the whole build.)
These data files should move to the module
> For the build to work on Windows, we need a unix compatibility layer (known
> as the "winenv" in the build system). This can be e.g. Cygwin or Msys. The
> build system then needs to adapt various aspect to get the build to work in
> this winenv. Over time, our current solutions (which were nev
On Thu, 3 Dec 2020 22:36:33 GMT, Magnus Ihse Bursie wrote:
>> make/CreateJmods.gmk line 172:
>>
>>> 170: endif
>>> 171: else # not java.base
>>> 172: ifeq ($(call isTargetOs, windows)+$(CREATING_BUILDJDK), true+false)
>>
>> This looks strange. Why would CREATING_BUILDJDK be relevant here?
>
44 matches
Mail list logo
