From some-java-user-99206970363698485155 at vodafonemail.de Fri Aug 7 15:22:45 2020 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Fri, 7 Aug 2020 17:22:45 +0200 (CEST) Subject: Why are there no short-circuiting compound assignment operators `&&=` and `||=`? In-Reply-To: <485078743.77383.1596149158617@mail.vodafone.de> References: <485078743.77383.1596149158617@mail.vodafone.de> Message-ID: <996400322.182650.1596813765650@mail.vodafone.de> Nearly all binary operators have a corresponding compound assignment operator. However, `&&` and `||` don't have a compound assignment operator so people often use `&=` or `|=` instead. These operators are not "short-circuiting", i.e. even if the right side has no effect on the assignment result it is evaluated nonetheless. The problem is that often the right side of the assignment is side-effect free and therefore calling it in these cases is inefficient, especially when its evaluation is expensive. Additionally these assignments are commonly used inside of loops which increases the inefficiency even further. It is possible to get the same behavior `&&=` and `||=` would provide: ``` boolean b = ... // b &&= testSomething() if (b) { b = testSomething(); } // b ||= testSomething() if (!b) { b = testSomething(); } ``` Though, these alternatives are slightly more verbose and add a level of indentation (unless you write the `if` statement in one line, which is however often discouraged). https://stackoverflow.com/q/2324549/ shows that there is interest in having these operators and there are no clear arguments why they don't exist yet. The question is therefore: Has the JDK team discussed adding these operators in the past and if so what where the reasons against adding them? From brian.goetz at oracle.com Mon Aug 10 21:53:01 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Aug 2020 17:53:01 -0400 Subject: Why are there no short-circuiting compound assignment operators `&&=` and `||=`? In-Reply-To: <996400322.182650.1596813765650@mail.vodafone.de> References: <485078743.77383.1596149158617@mail.vodafone.de> <996400322.182650.1596813765650@mail.vodafone.de> Message-ID: <112b88ea-e543-b72b-348d-6fa33f2c356c@oracle.com> > https://stackoverflow.com/q/2324549/ shows that there is interest in having these operators and there > are no clear arguments why they don't exist yet. > The question is therefore: Has the JDK team discussed adding these operators in the past and if so > what where the reasons against adding them? I'm not aware of any specific discussion on this particular issue, but if someone were to propose it, the answer would likely be: it's not an unreasonable request, but it doesn't carry its weight. "Carrying its weight" needs to be judged by its costs and benefits, and by its cost-benefit ratio relative to other candidate features. I think you are implicitly assuming (by the phrase "there is interest") that the cost is near zero and the benefit is greater than zero, so it seems an obvious win.? But this belies an incorrect understanding of cost; a feature like this affects the language spec, the implementation, the JCK, and every IDE and Java textbook. There are no trivial language features.? And the benefit, while nonzero, is pretty small. Secondarily, there are infinitely many features we _could_ do, but we only have capacity to do a handful every few years (and users have a limited capacity to absorb new features.)? So we have to be very careful as to which we pick, as each feature (even a trivial-seeming one) consumes some of this budget, and invariably takes it away from others.? It's not "why not this feature", but "what other features will we not do (or delay) so we can do this one, and is that a good trade?"? And I can't really imagine this being a good trade against anything else we're working on. So, it clears the bar of "not a terrible idea" (which is already pretty good, a lot of feature requests don't even clear that), but seems unlikely to ever clear the bar of "a better use of our evolution budget than anything else." From peter.lawrey at gmail.com Tue Aug 11 07:17:02 2020 From: peter.lawrey at gmail.com (Peter Lawrey) Date: Tue, 11 Aug 2020 08:17:02 +0100 Subject: Why are there no short-circuiting compound assignment operators `&&=` and `||=`? In-Reply-To: <112b88ea-e543-b72b-348d-6fa33f2c356c@oracle.com> References: <485078743.77383.1596149158617@mail.vodafone.de> <996400322.182650.1596813765650@mail.vodafone.de> <112b88ea-e543-b72b-348d-6fa33f2c356c@oracle.com> Message-ID: Hi, I would add you can write b = b && something() b = b || something() I suspect we only have as many assignment operators as we do because C had them. The most useful is += the rest don't add much IMHO. In terms of budget, another key resource is how much developers will remember and use effectively. Java assumes a lower budget requirement in this regard, which I believe is part of it's popularity. Personally I have a fairly high tolerance for complexity but most developers benefit from the language being as simple as possible. Regards Peter. On Mon, 10 Aug. 2020, 22:53 Brian Goetz, wrote: > > > > https://stackoverflow.com/q/2324549/ shows that there is interest in > having these operators and there > > are no clear arguments why they don't exist yet. > > The question is therefore: Has the JDK team discussed adding these > operators in the past and if so > > what where the reasons against adding them? > > I'm not aware of any specific discussion on this particular issue, but > if someone were to propose it, the answer would likely be: it's not an > unreasonable request, but it doesn't carry its weight. > > "Carrying its weight" needs to be judged by its costs and benefits, and > by its cost-benefit ratio relative to other candidate features. > > I think you are implicitly assuming (by the phrase "there is interest") > that the cost is near zero and the benefit is greater than zero, so it > seems an obvious win. But this belies an incorrect understanding of > cost; a feature like this affects the language spec, the implementation, > the JCK, and every IDE and Java textbook. There are no trivial language > features. And the benefit, while nonzero, is pretty small. > > Secondarily, there are infinitely many features we _could_ do, but we > only have capacity to do a handful every few years (and users have a > limited capacity to absorb new features.) So we have to be very careful > as to which we pick, as each feature (even a trivial-seeming one) > consumes some of this budget, and invariably takes it away from others. > It's not "why not this feature", but "what other features will we not do > (or delay) so we can do this one, and is that a good trade?" And I > can't really imagine this being a good trade against anything else we're > working on. > > So, it clears the bar of "not a terrible idea" (which is already pretty > good, a lot of feature requests don't even clear that), but seems > unlikely to ever clear the bar of "a better use of our evolution budget > than anything else." > From some-java-user-99206970363698485155 at vodafonemail.de Tue Aug 11 11:55:44 2020 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Tue, 11 Aug 2020 13:55:44 +0200 (CEST) Subject: Why are there no short-circuiting compound assignment operators `&&=` and `||=`? In-Reply-To: References: <485078743.77383.1596149158617@mail.vodafone.de> <996400322.182650.1596813765650@mail.vodafone.de> <112b88ea-e543-b72b-348d-6fa33f2c356c@oracle.com> Message-ID: <1522128168.513749.1597146944987@mail.vodafone.de> Thanks to both of you. When I wrote this mail I was indeed mostly thinking "it would be neat to have this feature" due to the cases I saw where it could be beneficial. However, I was not considering the overhead this small feature would cause. > how much developers will remember and use effectively This is a good point as well. The addition of these operators would likely not get the attention features like switch expressions or records get so most developers likely wouldn't even know that these operators exist and possibly instead even remember that the operators did not exist in the past. Though hopefully at least new programmers would at some point be aware of their existence. > most developers benefit from the language being as simple as possible If you know the concept of compound assignment operators and know the `&&` and `||` operators, then I don't think adding the respective compound operators for them would add more complexity. From Bruno.Borges at microsoft.com Tue Aug 18 22:42:20 2020 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Tue, 18 Aug 2020 22:42:20 +0000 Subject: Is G1GC the default in JDK 15 for any machine class/size? Message-ID: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> Hi, Up until JDK 14, SerialGC would be picked by default under certain conditions when the is_server_class_machine() returns false [1][2]. In JDK 15, at least on the binary available in the Docker image 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory or CPU is available to a container. I was not able to find in the source code of jdk15 where it is being indicated that G1GC should always be picked. So I am curious if anyone has observed this change in 15 and if so, where is this happening. Thanks, Bruno $ docker run -ti --memory=256m --cpus=1 openjdk:15-jdk-slim java -XX:+PrintFlagsFinal -version | grep "Use.*GC" bool UseAdaptiveSizeDecayMajorGCCost = true {product} {default} bool UseAdaptiveSizePolicyWithSystemGC = false {product} {default} bool UseDynamicNumberOfGCThreads = true {product} {default} bool UseG1GC = true {product} {ergonomic} bool UseGCOverheadLimit = true {product} {default} bool UseMaximumCompactionOnSystemGC = true {product} {default} bool UseParallelGC = false {product} {default} bool UseSerialGC = false {product} {default} bool UseShenandoahGC = false {product} {default} bool UseZGC = false {product} {default} [1] https://github.com/openjdk/jdk14/blob/master/src/hotspot/share/gc/shared/gcConfig.cpp#L103-L117 [2] https://github.com/openjdk/jdk14/blob/master/src/hotspot/share/runtime/os.cpp#L1604-L1637 From thomas.schatzl at oracle.com Wed Aug 19 08:45:57 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 19 Aug 2020 10:45:57 +0200 Subject: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> Message-ID: Hi, On 19.08.20 00:42, Bruno Borges wrote: > Hi, > > Up until JDK 14, SerialGC would be picked by default under certain conditions when the is_server_class_machine() returns false [1][2]. > > In JDK 15, at least on the binary available in the Docker image 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory or CPU is available to a container. Doesn't help you directly, but on bare metal, the detection works: $ numactl --physcpubind=1 bin/java -XX:+PrintFlagsFinal -version | egrep "UseSerialGC" gives bool UseSerialGC = true {product} {ergonomic} Can you enable os=trace logging on what the VM thinks what resources are available? > > I was not able to find in the source code of jdk15 where it is being indicated that G1GC should always be picked. You got the right location where the type of machine is determined. Thomas From Bruno.Borges at microsoft.com Fri Aug 21 20:48:46 2020 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Fri, 21 Aug 2020 20:48:46 +0000 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> Message-ID: <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> Hi Thomas, To clarify, this issue is being observed on Mac OS and Docker Desktop. And even though Docker Desktop for Mac runs a Linux VM behind the scenes, I was not able to reproduce this issue on a VirtualBox VM with Ubuntu, nor on a remote VM (also Ubuntu) running similar versions of containerd and Docker engine. Charlie Gracie noticed the following change that may be causing this issue. src/hotspot/os/linux/cgroupSubsystem_linux.cpp -- line 237: before, used to compare if moutinfo output is != 3 ++ line 292: now it compares whether it is equal to 4 It is unclear why this is only happening on Docker Desktop for macOS, and not on an Ubuntu VM on VirtualBox on the same machine. The only differences I could spot between Docker on the VBox machine and Docker Desktop for macOS are the following: - Docker Engine - ubuntu at vbox: 19.03.11 - dockerdesktop at macos: 19.03.12 - Go - ubuntu at vbox: 1.13.12 - dockerdesktop at macos: 1.13.10 - Linux Kernel - ubuntu at vbox: 5.4.0-42 - dockerdesktop at macos: 4.19.76-linuxkit This is output from Docker LinuxKit VM on my macOS. And more below you will see -Xlog:os=trace output with JDK 15. To access the Docker Desktop LinuxKit VM on Mac OS, you can do the following: $ docker container run --rm -it -v /:/host alpine / # chroot /host Once inside, you can get these outputs: ~ # docker version Client: Docker Engine - Community Version: 19.03.12 API version: 1.40 Go version: go1.13.10 Git commit: 48a66213fe Built: Mon Jun 22 15:42:52 2020 OS/Arch: linux/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 19.03.12 API version: 1.40 (minimum version 1.12) Go version: go1.13.10 Git commit: 48a66213fe Built: Mon Jun 22 15:49:27 2020 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.2.13 GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 runc: Version: 1.0.0-rc10 GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd docker-init: Version: 0.18.0 GitCommit: fec3683 And this is the docker run command with os=trace enabled: ~ # docker run -ti --memory=256m --cpus=1 openjdk:15-jdk-slim java -Xlog:os=trace,os+container=trace -version [0.000s][trace][os,container] OSContainer::init: Initializing Container Support [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.001s][debug][os,container] Required cgroup v1 memory subsystem not found [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.001s][debug][os ] Initial active processor count set to 4 [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.001s][trace][os ] total system memory: 2087837696 [0.001s][trace][os ] total system memory: 2087837696 [0.001s][info ][os ] Use of CLOCK_MONOTONIC is supported [0.001s][info ][os ] Use of pthread_condattr_setclock is supported [0.001s][info ][os ] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC [0.001s][info ][os ] HotSpot is running with glibc 2.28, NPTL 2.28 [0.001s][info ][os ] SafePoint Polling address, bad (protected) page:0x00007f50ea001000, good (unprotected) page:0x00007f50ea002000 [0.002s][info ][os ] attempting shared library load of /usr/local/openjdk-15/lib/libjava.so [0.002s][info ][os ] shared library load of /usr/local/openjdk-15/lib/libjava.so was successful [0.002s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.002s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.007s][trace][os ] total system memory: 2087837696 [0.020s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.020s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.030s][trace][os ] available memory: 150142976 [0.034s][trace][os ] available memory: 149884928 openjdk version "15" 2020-09-15 OpenJDK Runtime Environment (build 15+36-1562) OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) Running the same `docker run` command above with `openjdk:14-jdk-slim` instead, will give the right active_processor_count = 1. Hope this is helpful. bb. ?On 2020-08-19, 2:16 AM, "discuss on behalf of Thomas Schatzl" wrote: Hi, On 19.08.20 00:42, Bruno Borges wrote: > Hi, > > Up until JDK 14, SerialGC would be picked by default under certain conditions when the is_server_class_machine() returns false [1][2]. > > In JDK 15, at least on the binary available in the Docker image 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory or CPU is available to a container. Doesn't help you directly, but on bare metal, the detection works: $ numactl --physcpubind=1 bin/java -XX:+PrintFlagsFinal -version | egrep "UseSerialGC" gives bool UseSerialGC = true {product} {ergonomic} Can you enable os=trace logging on what the VM thinks what resources are available? > > I was not able to find in the source code of jdk15 where it is being indicated that G1GC should always be picked. You got the right location where the type of machine is determined. Thomas From Bruno.Borges at microsoft.com Sat Aug 22 08:31:41 2020 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Sat, 22 Aug 2020 08:31:41 +0000 Subject: Is G1GC the default in JDK 15 for any machine class/size? Message-ID: <4FD73E9D-3D97-4C58-B611-3264A3A733DF@microsoft.com> Confirmed this issue also happens with Docker Desktop for Windows, v 2.3.0.4 ?On 2020-08-21, 1:53 PM, "discuss on behalf of Bruno Borges" wrote: Hi Thomas, To clarify, this issue is being observed on Mac OS and Docker Desktop. And even though Docker Desktop for Mac runs a Linux VM behind the scenes, I was not able to reproduce this issue on a VirtualBox VM with Ubuntu, nor on a remote VM (also Ubuntu) running similar versions of containerd and Docker engine. Charlie Gracie noticed the following change that may be causing this issue. src/hotspot/os/linux/cgroupSubsystem_linux.cpp -- line 237: before, used to compare if moutinfo output is != 3 ++ line 292: now it compares whether it is equal to 4 It is unclear why this is only happening on Docker Desktop for macOS, and not on an Ubuntu VM on VirtualBox on the same machine. The only differences I could spot between Docker on the VBox machine and Docker Desktop for macOS are the following: - Docker Engine - ubuntu at vbox: 19.03.11 - dockerdesktop at macos: 19.03.12 - Go - ubuntu at vbox: 1.13.12 - dockerdesktop at macos: 1.13.10 - Linux Kernel - ubuntu at vbox: 5.4.0-42 - dockerdesktop at macos: 4.19.76-linuxkit This is output from Docker LinuxKit VM on my macOS. And more below you will see -Xlog:os=trace output with JDK 15. To access the Docker Desktop LinuxKit VM on Mac OS, you can do the following: $ docker container run --rm -it -v /:/host alpine / # chroot /host Once inside, you can get these outputs: ~ # docker version Client: Docker Engine - Community Version: 19.03.12 API version: 1.40 Go version: go1.13.10 Git commit: 48a66213fe Built: Mon Jun 22 15:42:52 2020 OS/Arch: linux/amd64 Experimental: false Server: Docker Engine - Community Engine: Version: 19.03.12 API version: 1.40 (minimum version 1.12) Go version: go1.13.10 Git commit: 48a66213fe Built: Mon Jun 22 15:49:27 2020 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.2.13 GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 runc: Version: 1.0.0-rc10 GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd docker-init: Version: 0.18.0 GitCommit: fec3683 And this is the docker run command with os=trace enabled: ~ # docker run -ti --memory=256m --cpus=1 openjdk:15-jdk-slim java -Xlog:os=trace,os+container=trace -version [0.000s][trace][os,container] OSContainer::init: Initializing Container Support [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.001s][debug][os,container] Required cgroup v1 memory subsystem not found [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.001s][debug][os ] Initial active processor count set to 4 [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.001s][trace][os ] total system memory: 2087837696 [0.001s][trace][os ] total system memory: 2087837696 [0.001s][info ][os ] Use of CLOCK_MONOTONIC is supported [0.001s][info ][os ] Use of pthread_condattr_setclock is supported [0.001s][info ][os ] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC [0.001s][info ][os ] HotSpot is running with glibc 2.28, NPTL 2.28 [0.001s][info ][os ] SafePoint Polling address, bad (protected) page:0x00007f50ea001000, good (unprotected) page:0x00007f50ea002000 [0.002s][info ][os ] attempting shared library load of /usr/local/openjdk-15/lib/libjava.so [0.002s][info ][os ] shared library load of /usr/local/openjdk-15/lib/libjava.so was successful [0.002s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.002s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.007s][trace][os ] total system memory: 2087837696 [0.020s][trace][os ] active_processor_count: using static path - configured processors: 4 [0.020s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 [0.030s][trace][os ] available memory: 150142976 [0.034s][trace][os ] available memory: 149884928 openjdk version "15" 2020-09-15 OpenJDK Runtime Environment (build 15+36-1562) OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) Running the same `docker run` command above with `openjdk:14-jdk-slim` instead, will give the right active_processor_count = 1. Hope this is helpful. bb. On 2020-08-19, 2:16 AM, "discuss on behalf of Thomas Schatzl" wrote: Hi, On 19.08.20 00:42, Bruno Borges wrote: > Hi, > > Up until JDK 14, SerialGC would be picked by default under certain conditions when the is_server_class_machine() returns false [1][2]. > > In JDK 15, at least on the binary available in the Docker image 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory or CPU is available to a container. Doesn't help you directly, but on bare metal, the detection works: $ numactl --physcpubind=1 bin/java -XX:+PrintFlagsFinal -version | egrep "UseSerialGC" gives bool UseSerialGC = true {product} {ergonomic} Can you enable os=trace logging on what the VM thinks what resources are available? > > I was not able to find in the source code of jdk15 where it is being indicated that G1GC should always be picked. You got the right location where the type of machine is determined. Thomas From sgehwolf at redhat.com Mon Aug 24 09:32:33 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 24 Aug 2020 11:32:33 +0200 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> Message-ID: Hi Bruno, On Fri, 2020-08-21 at 20:48 +0000, Bruno Borges wrote: > Hi Thomas, > > To clarify, this issue is being observed on Mac OS and Docker > Desktop. And even though Docker Desktop for Mac runs a Linux VM > behind the scenes, I was not able to reproduce this issue on a > VirtualBox VM with Ubuntu, nor on a remote VM (also Ubuntu) running > similar versions of containerd and Docker engine. > > Charlie Gracie noticed the following change that may be causing this > issue. > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp > > -- line 237: before, used to compare if moutinfo output is != 3 > ++ line 292: now it compares whether it is equal to 4 OK. How does /proc/self/mountinfo look like on this setup? Same for /proc/cgroups and /proc/self/cgroup files. It might help diagnose the issue. Please put them into a bug report if possible. > It is unclear why this is only happening on Docker Desktop for macOS, > and not on an Ubuntu VM on VirtualBox on the same machine. The only > differences I could spot between Docker on the VBox machine and > Docker Desktop for macOS are the following: > > - Docker Engine > - ubuntu at vbox: 19.03.11 > - dockerdesktop at macos: 19.03.12 > > - Go > - ubuntu at vbox: 1.13.12 > - dockerdesktop at macos: 1.13.10 > > - Linux Kernel > - ubuntu at vbox: 5.4.0-42 > - dockerdesktop at macos: 4.19.76-linuxkit > > This is output from Docker LinuxKit VM on my macOS. And more below > you will see -Xlog:os=trace output with JDK 15. I'd suspect this might be caused by how these kernels set up cgroup files. Your container trace output suggests that container detection isn't working as expected in this kind of setup. > To access the Docker Desktop LinuxKit VM on Mac OS, you can do the > following: > > $ docker container run --rm -it -v /:/host alpine > / # chroot /host > > Once inside, you can get these outputs: > > ~ # docker version > Client: Docker Engine - Community > Version: 19.03.12 > API version: 1.40 > Go version: go1.13.10 > Git commit: 48a66213fe > Built: Mon Jun 22 15:42:52 2020 > OS/Arch: linux/amd64 > Experimental: false > > Server: Docker Engine - Community > Engine: > Version: 19.03.12 > API version: 1.40 (minimum version 1.12) > Go version: go1.13.10 > Git commit: 48a66213fe > Built: Mon Jun 22 15:49:27 2020 > OS/Arch: linux/amd64 > Experimental: false > containerd: > Version: v1.2.13 > GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 > runc: > Version: 1.0.0-rc10 > GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd > docker-init: > Version: 0.18.0 > GitCommit: fec3683 > > And this is the docker run command with os=trace enabled: > > ~ # docker run -ti --memory=256m --cpus=1 openjdk:15-jdk-slim java -Xlog:os=trace,os+container=trace -version > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.001s][debug][os,container] Required cgroup v1 memory subsystem not found This seems an indication of a failure in the container detection code. > [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.001s][debug][os ] Initial active processor count set to 4 > [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.001s][trace][os ] total system memory: 2087837696 > [0.001s][trace][os ] total system memory: 2087837696 > [0.001s][info ][os ] Use of CLOCK_MONOTONIC is supported > [0.001s][info ][os ] Use of pthread_condattr_setclock is supported > [0.001s][info ][os ] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC > [0.001s][info ][os ] HotSpot is running with glibc 2.28, NPTL 2.28 > [0.001s][info ][os ] SafePoint Polling address, bad (protected) page:0x00007f50ea001000, good (unprotected) page:0x00007f50ea002000 > [0.002s][info ][os ] attempting shared library load of /usr/local/openjdk-15/lib/libjava.so > [0.002s][info ][os ] shared library load of /usr/local/openjdk-15/lib/libjava.so was successful > [0.002s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.002s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.007s][trace][os ] total system memory: 2087837696 > [0.020s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.020s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.030s][trace][os ] available memory: 150142976 > [0.034s][trace][os ] available memory: 149884928 > openjdk version "15" 2020-09-15 > OpenJDK Runtime Environment (build 15+36-1562) > OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) > > > Running the same `docker run` command above with `openjdk:14-jdk- > slim` instead, will give the right active_processor_count = 1. OK. Seems like a regression from JDK 14 then. In JDK 15 we've added cgroups v2 support: https://bugs.openjdk.java.net/browse/JDK-8230305 We should get a bug created for this container detection issue and gather additional info there. Would you be willing to do this? Perhaps a test failure would be reproducible on such a system with one of the docker tests in: test/hotspot/jtreg/containers/docker test/jdk/jdk/internal/platform/docker In the meantime, you should be able to override CPU count with -XX:ActiveProcessorCount=1 and memory with -XX:MaxRAM=256m and should see SerialGC being selected in docker as Thomas pointed out earlier. ./bin/java -XX:ActiveProcessorCount=1 -XX:MaxRAM=256m -XX:+PrintFlagsFinal -version 2>&1 | grep Use | grep GC bool UseAdaptiveGCBoundary = false {product} {default} bool UseAdaptiveSizeDecayMajorGCCost = true {product} {default} bool UseAdaptiveSizePolicyWithSystemGC = false {product} {default} bool UseDynamicNumberOfGCThreads = true {product} {default} bool UseG1GC = false {product} {default} bool UseGCOverheadLimit = true {product} {default} bool UseMaximumCompactionOnSystemGC = true {product} {default} bool UseParallelGC = false {product} {default} bool UseSerialGC = true {product} {ergonomic} Thanks, Severin > Hope this is helpful. > > bb. > > ?On 2020-08-19, 2:16 AM, "discuss on behalf of Thomas Schatzl" < > discuss-retn at openjdk.java.net on behalf of thomas.schatzl at oracle.com> > wrote: > > Hi, > > On 19.08.20 00:42, Bruno Borges wrote: > > Hi, > > > > Up until JDK 14, SerialGC would be picked by default under > certain conditions when the is_server_class_machine() returns false > [1][2]. > > > > In JDK 15, at least on the binary available in the Docker image > 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory > or CPU is available to a container. > > Doesn't help you directly, but on bare metal, the detection > works: > > $ numactl --physcpubind=1 bin/java -XX:+PrintFlagsFinal -version > | egrep > "UseSerialGC" > > gives > > bool UseSerialGC = true > {product} {ergonomic} > > Can you enable os=trace logging on what the VM thinks what > resources are > available? > > > > > I was not able to find in the source code of jdk15 where it is > being indicated that G1GC should always be picked. > > You got the right location where the type of machine is > determined. > > Thomas > From thomas.stuefe at gmail.com Mon Aug 24 11:48:15 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Aug 2020 13:48:15 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? Message-ID: Hi, Anyone else experiencing slow access to openjdk.java.net or is it just me? Accessing anything takes 4-6 minutes per http access from my cable provider in Germany. As a related question, would it make sense to have some mailing list for informing about and keeping track of outages like this (see e.g. the recent mailing list problems)? There is ops at openjdk.java.net but that is not a public list. So all discussions there are 1:1 between the outside reporter and whoever at Oracle monitors that mail address. Cheers, Thomas From rkennke at redhat.com Mon Aug 24 20:15:15 2020 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 24 Aug 2020 22:15:15 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: References: Message-ID: <5d32cb76e90c9350f4160043d23c3bf971d7db55.camel@redhat.com> Me too. Roman Am Montag, den 24.08.2020, 13:48 +0200 schrieb Thomas St?fe: > Hi, > > Anyone else experiencing slow access to openjdk.java.net or is it > just me? > Accessing anything takes 4-6 minutes per http access from my cable > provider > in Germany. > > As a related question, would it make sense to have some mailing list > for > informing about and keeping track of outages like this (see e.g. the > recent > mailing list problems)? There is ops at openjdk.java.net but that is not > a > public list. So all discussions there are 1:1 between the outside > reporter > and whoever at Oracle monitors that mail address. > > Cheers, Thomas > From sormuras at gmail.com Tue Aug 25 06:00:43 2020 From: sormuras at gmail.com (Christian Stein) Date: Tue, 25 Aug 2020 08:00:43 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: References: Message-ID: I noticed the outage early yesterday [*] and reported it to Dalibor via PM. He routed the issue internally -- perhaps, I'll write to the "web-discuss" ML next time. Its subtitle seems to be a fit: "Discussions about the openjdk.java.net site infrastructure" https://mail.openjdk.java.net/mailman/listinfo/web-discuss Cheers, Christian [*] I run a script every 4 hours scanning the HTML pages of https://jdk.java.net/ in order to update a list of available JDK distros via GitHub Actions: https://github.com/sormuras/bach/actions?query=workflow%3A%22Update+install-jdk.properties%22 On Mon, Aug 24, 2020 at 8:23 PM Thomas St?fe wrote: > Hi, > > Anyone else experiencing slow access to openjdk.java.net or is it just me? > Accessing anything takes 4-6 minutes per http access from my cable provider > in Germany. > > As a related question, would it make sense to have some mailing list for > informing about and keeping track of outages like this (see e.g. the recent > mailing list problems)? There is ops at openjdk.java.net but that is not a > public list. So all discussions there are 1:1 between the outside reporter > and whoever at Oracle monitors that mail address. > > Cheers, Thomas > From sormuras at gmail.com Tue Aug 25 06:46:33 2020 From: sormuras at gmail.com (Christian Stein) Date: Tue, 25 Aug 2020 08:46:33 +0200 Subject: Call for Discussion: jbuild Message-ID: Hi, I would like to discuss the possible creation of a lightweight build tool for modular Java projects included in the JDK itself: jbuild The JDK contains a set of foundation tools [1] but none of them guides developers from processing Java source files into shippable products: be it a reusable modular JAR file with its API documentation or an entire custom (soon static [2]) runtime image. There exists an implicit workflow encoded in the available options of the foundation tools. The (binary) output of one tool is the input of one or more tools. With the introduction of modules in Java 9 some structural parts of that workflow got a) promoted into the language itself and b) resulted in explicit module system-related tool options. These structural information, encoded explicitly by developers in Java's module descriptors, can be used as basic building blocks when describing a modular Java project. I think of it as a "project-info.java" file -- which I don't propose to introduce (as a part of the language) -- but it helps to transport the jbuild idea. With assets from the "Greetings world" example [3] a fictitious project descriptor could read like: ``` project greet { version 1-ea; modules com.greetings,org.astro; main-module com.greetings; module com.greetings { main-class com.greetings.Main; } } ``` Based on such a project descriptor jbuild should call existing (and future) JDK tools in the right order with the right arguments. Nothing more, nothing less. It would expand to the following (trimmed) foundation tool calls by parsing basic information about the modular project structure from module-info.java and other source files: ``` javac --module com.greetings,org.astro jar --file com.greetings at 1-ea.jar --main-class com.greetings.Main jar --file org.astro at 1-ea.jar javadoc --module com.greetings,org.astro jar --file greet at 1-ea-api.jar jlink --add-modules com.greetings,org.astro --launcher greet=com.greetings ``` Find a more detailed motivation description at [4]. ## Goals jbuild targets modular Java projects that follow common practices and patterns in structure and build steps; as defined and supported by the underlying foundation tools. The goal is to create a build tool that... - is a lightweight wrapper for existing and future foundation tools of the JDK. - can be invoked directly from the command line, or programmatically, either via the `ToolProvider` SPI or via its modular API (in a JShell session). - infers basic project information from `module-info.java` files. - uses standard Java syntax for configuration purposes - supports creation of MR-JAR modules. - helps resolving missing external dependencies by downloading required modules into a single project-local directory. - knows how to run test modules via the `ToolProvider` API. - launches the JUnit Platform [5] -- if it is provided by the project. ## Non-Goals There will be no support for "all features known from other build tools". If a feature F is not already provided by a foundation tool, this build tool will not support F. If F is required to build modular Java projects, F should be implemented by a foundation tool If F is absolutely required to build modular Java projects and its implementation would induce changes in multiple foundation tools, this build tool will support F. The build tool will/should/must **not**... - support non-Java projects. - support non-modular Java projects. - provide a GUI for the tool. - resolve conflicting external dependencies. - deploy modules to external services. Comments? Cheers, Christian [1]: https://docs.oracle.com/en/java/javase/14/docs/specs/man/index.html [2]: https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html [3]: https://openjdk.java.net/projects/jigsaw/quick-start#greetingsworld [4]: https://github.com/sormuras/bach/blob/11.7/doc/motivation.md [5]: https://junit.org/junit5 From Bruno.Borges at microsoft.com Tue Aug 25 08:05:07 2020 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Tue, 25 Aug 2020 08:05:07 +0000 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> Message-ID: <3A13BE15-79B8-4D3C-9F59-86D5856CB3C6@microsoft.com> Hi Severin, Issue created: 9066610. Charlie has a fix to propose. Perhaps we can push that once the bug is reviewed? ?On 2020-08-24, 2:32 AM, "Severin Gehwolf" wrote: Hi Bruno, On Fri, 2020-08-21 at 20:48 +0000, Bruno Borges wrote: > Hi Thomas, > > To clarify, this issue is being observed on Mac OS and Docker > Desktop. And even though Docker Desktop for Mac runs a Linux VM > behind the scenes, I was not able to reproduce this issue on a > VirtualBox VM with Ubuntu, nor on a remote VM (also Ubuntu) running > similar versions of containerd and Docker engine. > > Charlie Gracie noticed the following change that may be causing this > issue. > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp > > -- line 237: before, used to compare if moutinfo output is != 3 > ++ line 292: now it compares whether it is equal to 4 OK. How does /proc/self/mountinfo look like on this setup? Same for /proc/cgroups and /proc/self/cgroup files. It might help diagnose the issue. Please put them into a bug report if possible. > It is unclear why this is only happening on Docker Desktop for macOS, > and not on an Ubuntu VM on VirtualBox on the same machine. The only > differences I could spot between Docker on the VBox machine and > Docker Desktop for macOS are the following: > > - Docker Engine > - ubuntu at vbox: 19.03.11 > - dockerdesktop at macos: 19.03.12 > > - Go > - ubuntu at vbox: 1.13.12 > - dockerdesktop at macos: 1.13.10 > > - Linux Kernel > - ubuntu at vbox: 5.4.0-42 > - dockerdesktop at macos: 4.19.76-linuxkit > > This is output from Docker LinuxKit VM on my macOS. And more below > you will see -Xlog:os=trace output with JDK 15. I'd suspect this might be caused by how these kernels set up cgroup files. Your container trace output suggests that container detection isn't working as expected in this kind of setup. > To access the Docker Desktop LinuxKit VM on Mac OS, you can do the > following: > > $ docker container run --rm -it -v /:/host alpine > / # chroot /host > > Once inside, you can get these outputs: > > ~ # docker version > Client: Docker Engine - Community > Version: 19.03.12 > API version: 1.40 > Go version: go1.13.10 > Git commit: 48a66213fe > Built: Mon Jun 22 15:42:52 2020 > OS/Arch: linux/amd64 > Experimental: false > > Server: Docker Engine - Community > Engine: > Version: 19.03.12 > API version: 1.40 (minimum version 1.12) > Go version: go1.13.10 > Git commit: 48a66213fe > Built: Mon Jun 22 15:49:27 2020 > OS/Arch: linux/amd64 > Experimental: false > containerd: > Version: v1.2.13 > GitCommit: 7ad184331fa3e55e52b890ea95e65ba581ae3429 > runc: > Version: 1.0.0-rc10 > GitCommit: dc9208a3303feef5b3839f4323d9beb36df0a9dd > docker-init: > Version: 0.18.0 > GitCommit: fec3683 > > And this is the docker run command with os=trace enabled: > > ~ # docker run -ti --memory=256m --cpus=1 openjdk:15-jdk-slim java -Xlog:os=trace,os+container=trace -version > [0.000s][trace][os,container] OSContainer::init: Initializing Container Support > [0.001s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers > [0.001s][debug][os,container] Required cgroup v1 memory subsystem not found This seems an indication of a failure in the container detection code. > [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.001s][debug][os ] Initial active processor count set to 4 > [0.001s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.001s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.001s][trace][os ] total system memory: 2087837696 > [0.001s][trace][os ] total system memory: 2087837696 > [0.001s][info ][os ] Use of CLOCK_MONOTONIC is supported > [0.001s][info ][os ] Use of pthread_condattr_setclock is supported > [0.001s][info ][os ] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC > [0.001s][info ][os ] HotSpot is running with glibc 2.28, NPTL 2.28 > [0.001s][info ][os ] SafePoint Polling address, bad (protected) page:0x00007f50ea001000, good (unprotected) page:0x00007f50ea002000 > [0.002s][info ][os ] attempting shared library load of /usr/local/openjdk-15/lib/libjava.so > [0.002s][info ][os ] shared library load of /usr/local/openjdk-15/lib/libjava.so was successful > [0.002s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.002s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.007s][trace][os ] total system memory: 2087837696 > [0.020s][trace][os ] active_processor_count: using static path - configured processors: 4 > [0.020s][trace][os ] active_processor_count: sched_getaffinity processor count: 4 > [0.030s][trace][os ] available memory: 150142976 > [0.034s][trace][os ] available memory: 149884928 > openjdk version "15" 2020-09-15 > OpenJDK Runtime Environment (build 15+36-1562) > OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing) > > > Running the same `docker run` command above with `openjdk:14-jdk- > slim` instead, will give the right active_processor_count = 1. OK. Seems like a regression from JDK 14 then. In JDK 15 we've added cgroups v2 support: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8230305&data=02%7C01%7Cbruno.borges%40microsoft.com%7C2d29ffe814b145bbb00408d84810a72f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637338583650701696&sdata=fI86rKR7a5%2F2I70KEC%2F6brC2dY5KlROWSEoG8JukEPc%3D&reserved=0 We should get a bug created for this container detection issue and gather additional info there. Would you be willing to do this? Perhaps a test failure would be reproducible on such a system with one of the docker tests in: test/hotspot/jtreg/containers/docker test/jdk/jdk/internal/platform/docker In the meantime, you should be able to override CPU count with -XX:ActiveProcessorCount=1 and memory with -XX:MaxRAM=256m and should see SerialGC being selected in docker as Thomas pointed out earlier. ./bin/java -XX:ActiveProcessorCount=1 -XX:MaxRAM=256m -XX:+PrintFlagsFinal -version 2>&1 | grep Use | grep GC bool UseAdaptiveGCBoundary = false {product} {default} bool UseAdaptiveSizeDecayMajorGCCost = true {product} {default} bool UseAdaptiveSizePolicyWithSystemGC = false {product} {default} bool UseDynamicNumberOfGCThreads = true {product} {default} bool UseG1GC = false {product} {default} bool UseGCOverheadLimit = true {product} {default} bool UseMaximumCompactionOnSystemGC = true {product} {default} bool UseParallelGC = false {product} {default} bool UseSerialGC = true {product} {ergonomic} Thanks, Severin > Hope this is helpful. > > bb. > > On 2020-08-19, 2:16 AM, "discuss on behalf of Thomas Schatzl" < > discuss-retn at openjdk.java.net on behalf of thomas.schatzl at oracle.com> > wrote: > > Hi, > > On 19.08.20 00:42, Bruno Borges wrote: > > Hi, > > > > Up until JDK 14, SerialGC would be picked by default under > certain conditions when the is_server_class_machine() returns false > [1][2]. > > > > In JDK 15, at least on the binary available in the Docker image > 'openjdk/15-jdk-slim', G1GC is being picked no matter how much memory > or CPU is available to a container. > > Doesn't help you directly, but on bare metal, the detection > works: > > $ numactl --physcpubind=1 bin/java -XX:+PrintFlagsFinal -version > | egrep > "UseSerialGC" > > gives > > bool UseSerialGC = true > {product} {ergonomic} > > Can you enable os=trace logging on what the VM thinks what > resources are > available? > > > > > I was not able to find in the source code of jdk15 where it is > being indicated that G1GC should always be picked. > > You got the right location where the type of machine is > determined. > > Thomas > From volker.simonis at gmail.com Tue Aug 25 08:07:51 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 25 Aug 2020 10:07:51 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: References: Message-ID: I have reported this yesterday [1] and now it seems to be fixed. +1 for the proposal to make ops at openjdk.java.net a public email list instead of an alias. Adding ops and Tim Bell who at least for me is "Mr. Ops :)". @Tim: what do you think, wouldn't it be a good idea to make ops at openjdk.java.net a public mailing list instead of an email alias? Everybody could then see if problems already have been reported and it could also be used to notify everybody if problems have been fixed. Best regards, Volker [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004653.html On Mon, Aug 24, 2020 at 8:23 PM Thomas St?fe wrote: > > Hi, > > Anyone else experiencing slow access to openjdk.java.net or is it just me? > Accessing anything takes 4-6 minutes per http access from my cable provider > in Germany. > > As a related question, would it make sense to have some mailing list for > informing about and keeping track of outages like this (see e.g. the recent > mailing list problems)? There is ops at openjdk.java.net but that is not a > public list. So all discussions there are 1:1 between the outside reporter > and whoever at Oracle monitors that mail address. > > Cheers, Thomas From sgehwolf at redhat.com Tue Aug 25 08:37:52 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 25 Aug 2020 10:37:52 +0200 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: <3A13BE15-79B8-4D3C-9F59-86D5856CB3C6@microsoft.com> References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> <3A13BE15-79B8-4D3C-9F59-86D5856CB3C6@microsoft.com> Message-ID: Hi Bruno, On Tue, 2020-08-25 at 08:05 +0000, Bruno Borges wrote: > Hi Severin, > > Issue created: 9066610. Thanks. We might need somebody from Oracle to push this one through to https://bugs.openjdk.java.net. 9XXXX bugs are AFAIK created by the web- interface and need active triage to show up as JDK-8XXXX bugs. > Charlie has a fix to propose. Great! Looking forward to it. Thanks, Severin From Bruno.Borges at microsoft.com Tue Aug 25 09:29:24 2020 From: Bruno.Borges at microsoft.com (Bruno Borges) Date: Tue, 25 Aug 2020 09:29:24 +0000 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> <3A13BE15-79B8-4D3C-9F59-86D5856CB3C6@microsoft.com> Message-ID: <2025F2C4-EA11-47C1-93ED-DC605AA2484A@microsoft.com> No worries. I am not aware of any other way for non-OpenJDK Authors to submit a bug to OpenJDK except through bugreport.java.com. If there is, happy to follow that for any future issue. bb. ?On 2020-08-25, 1:38 AM, "Severin Gehwolf" wrote: Hi Bruno, On Tue, 2020-08-25 at 08:05 +0000, Bruno Borges wrote: > Hi Severin, > > Issue created: 9066610. Thanks. We might need somebody from Oracle to push this one through to https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2F&data=02%7C01%7Cbruno.borges%40microsoft.com%7Cd42960c0f337432eb91f08d848d22d34%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637339414829321635&sdata=tiISMNYLWMICCuA3GAgpxs9EMXUHtBdjMYc%2FEk%2Bx9%2Bo%3D&reserved=0. 9XXXX bugs are AFAIK created by the web- interface and need active triage to show up as JDK-8XXXX bugs. > Charlie has a fix to propose. Great! Looking forward to it. Thanks, Severin From aph at redhat.com Tue Aug 25 10:25:52 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 11:25:52 +0100 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: References: Message-ID: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> On 25/08/2020 09:07, Volker Simonis wrote: > @Tim: what do you think, wouldn't it be a good idea to make > ops at openjdk.java.net a public mailing list instead of an email alias? > Everybody could then see if problems already have been reported and it > could also be used to notify everybody if problems have been fixed. What if you want to tell ops@ something that you don't want broadcast to the universe and archived forever? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Tue Aug 25 10:30:07 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Aug 2020 12:30:07 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> References: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> Message-ID: <3adf0c5d4f08955d019085b85844411f0e22bc1f.camel@redhat.com> Am Dienstag, den 25.08.2020, 11:25 +0100 schrieb Andrew Haley: > On 25/08/2020 09:07, Volker Simonis wrote: > > @Tim: what do you think, wouldn't it be a good idea to make > > ops at openjdk.java.net a public mailing list instead of an email > > alias? > > Everybody could then see if problems already have been reported and > > it > > could also be used to notify everybody if problems have been fixed. > > What if you want to tell ops@ something that you don't want > broadcast to the universe and archived forever? IMO, an (moderated) email-list like ops-announce or something would be good enough, for broadcasting known outages and their resolution. Or even a website to check if something's known. Then, when I experience a problem I would check that first, and if it's not announced yet, I'd go ahead and send to ops@ as usual. I don't see much need for public discussions about outages. Roman From thomas.stuefe at gmail.com Tue Aug 25 10:52:39 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 25 Aug 2020 12:52:39 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: <3adf0c5d4f08955d019085b85844411f0e22bc1f.camel@redhat.com> References: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> <3adf0c5d4f08955d019085b85844411f0e22bc1f.camel@redhat.com> Message-ID: On Tue, Aug 25, 2020 at 12:30 PM Roman Kennke wrote: > Am Dienstag, den 25.08.2020, 11:25 +0100 schrieb Andrew Haley: > > On 25/08/2020 09:07, Volker Simonis wrote: > > > @Tim: what do you think, wouldn't it be a good idea to make > > > ops at openjdk.java.net a public mailing list instead of an email > > > alias? > > > Everybody could then see if problems already have been reported and > > > it > > > could also be used to notify everybody if problems have been fixed. > > > > What if you want to tell ops@ something that you don't want > > broadcast to the universe and archived forever? > > IMO, an (moderated) email-list like ops-announce or something would be > good enough, for broadcasting known outages and their resolution. Or > even a website to check if something's known. Then, when I experience a > problem I would check that first, and if it's not announced yet, I'd go > ahead and send to ops@ as usual. I don't see much need for public > discussions about outages. > > Roman > > +1 ..Thomas From volker.simonis at gmail.com Tue Aug 25 10:54:02 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 25 Aug 2020 12:54:02 +0200 Subject: openjdk.java.net outage? Also, could we track these outages publicly? In-Reply-To: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> References: <96976477-292c-e1bb-be16-1c810071b651@redhat.com> Message-ID: On Tue, Aug 25, 2020 at 12:26 PM Andrew Haley wrote: > > On 25/08/2020 09:07, Volker Simonis wrote: > > @Tim: what do you think, wouldn't it be a good idea to make > > ops at openjdk.java.net a public mailing list instead of an email alias? > > Everybody could then see if problems already have been reported and it > > could also be used to notify everybody if problems have been fixed. > > What if you want to tell ops@ something that you don't want > broadcast to the universe and archived forever? I have nothing against creating a public mailing list for infrastructure problems in addition to the ops email alias. But the current situation is a little unsatisfactory for both users and oops because: - if you encounter an infra problem you can't know if it has been reported and acknowledged already (e.g. yesterday I reported an issue on jdk-dev and hotspot-dev, Thomas reported the same issue on discuss and Christian to web-discuss) - ops will get multiple reports for the same problem - there's no place for ops to post the resolution of an issue. I don't see a problem to broadcast most of the infrastructure issues to the universe and archive them forever. I think this might be even beneficial, because it allows us to do some statistics of what failed how often which might be useful for improving things in the future. Best regrds, Volker > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From david.holmes at oracle.com Wed Aug 26 07:06:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Aug 2020 17:06:03 +1000 Subject: [EXTERNAL] Re: Is G1GC the default in JDK 15 for any machine class/size? In-Reply-To: <2025F2C4-EA11-47C1-93ED-DC605AA2484A@microsoft.com> References: <26B21854-6984-4825-827A-E9A4BCEACC34@microsoft.com> <4EB174E4-F171-4A31-A38A-4AB4313C0958@microsoft.com> <3A13BE15-79B8-4D3C-9F59-86D5856CB3C6@microsoft.com> <2025F2C4-EA11-47C1-93ED-DC605AA2484A@microsoft.com> Message-ID: Please note that the discuss at openjdk.java.net mailing list is not the appropriate place to discuss this kind of issue. hotspot-runtime-dev would be the correct place to discuss this. Thanks, David On 25/08/2020 7:29 pm, Bruno Borges wrote: > No worries. > > I am not aware of any other way for non-OpenJDK Authors to submit a bug to OpenJDK except through bugreport.java.com. If there is, happy to follow that for any future issue. > > bb. > > ?On 2020-08-25, 1:38 AM, "Severin Gehwolf" wrote: > > Hi Bruno, > > On Tue, 2020-08-25 at 08:05 +0000, Bruno Borges wrote: > > Hi Severin, > > > > Issue created: 9066610. > > Thanks. We might need somebody from Oracle to push this one through to > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2F&data=02%7C01%7Cbruno.borges%40microsoft.com%7Cd42960c0f337432eb91f08d848d22d34%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637339414829321635&sdata=tiISMNYLWMICCuA3GAgpxs9EMXUHtBdjMYc%2FEk%2Bx9%2Bo%3D&reserved=0. 9XXXX bugs are AFAIK created by the web- > interface and need active triage to show up as JDK-8XXXX bugs. > > > Charlie has a fix to propose. > > Great! Looking forward to it. > > Thanks, > Severin > >