corretto / corretto-17 Goto Github PK

Amazon Corretto 17 is a no-cost, multi-platform, production-ready distribution of OpenJDK 17

License: GNU General Public License v2.0

Makefile 0.01% Shell 0.17% JavaScript 0.02% M4 0.14% sed 0.01% Roff 0.17% HTML 0.33% CSS 0.01% Python 0.05% Java 76.52% XSLT 0.25% Batchfile 0.01% Perl 0.01% C++ 13.59% C 5.90% DTrace 0.01% Assembly 2.42% GDB 0.01% Objective-C 0.42% Mathematica 0.01%

corretto-17's Introduction

Corretto JDK

Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK). Corretto is used internally at Amazon for production services. With Corretto, you can develop and run Java applications on operating systems such as Linux, Windows, and macOS.

This repository is used to track OpenJDK upstream tip. Please look at the branches section for more information on Feature Releases.

The latest binary Corretto 17 release builds can be downloaded from https://github.com/corretto/corretto-17/releases.

Documentation is available at https://docs.aws.amazon.com/corretto.

Licenses and Trademarks

Please read these files: "LICENSE", "ADDITIONAL_LICENSE_INFO", "ASSEMBLY_EXCEPTION", "TRADEMARKS.md".

Branches

develop : The default branch. The branch that consumes development and patches to upstream jdk17u. Corretto builds are generated from this branch.

upstream-jdk17 : The branch is similar to master at openjdk/jdk17. This branch merges into release branches.

upstream-jdk17u : The branch is similar to master at openjdk/jdk17u. This branch merges into develop.

OpenJDK Readme


Welcome to the JDK!
===================

For build instructions, please see either of these files:

  * doc/building.html   (html version)
  * doc/building.md     (markdown version)

See https://openjdk.java.net/ for more information about
the OpenJDK Community and the JDK.

corretto-17's People

Contributors

Stargazers

Watchers

Forkers

caojoshua mrserb lutkerd simonis i-spark alvdavi astra-zhao terminalcoders cliveverghese olivergillespie classicvalues ehsaniara shyamalschandra earthling-amzn yogeshvarathan rudometov leibf2099 paul-amonson solution17god lukkns pengzonli anggarasatria yftsai programmingmuffin elifaslan1 autumn808 pkcom-m-myohara davecurrie rgithubli mohammad2731 benty-amzn snazarkin clownsw patrickthestarfish01 defconx shipilev sandipanchakraborty2016 ysramakrishna pgmjun aaaapai straiforos eastig chadrako pks-os

corretto-17's Issues

A fatal error has been detected by the Java Runtime Environment

hs_err_pid165095.log
replay_pid165095.log

it keeps happening, after a couple of hours of running the program, i tried old jdk 11 lts, and it worked just fine

Swing application UI freezes at sun.lwawt.macosx.CAccessibility.getChildrenAndRoles

In my Swing application, I utilize a JTree component with approximately 120 TreeNodes. Each node has around 100-120 child nodes, spanning up to three hierarchical steps. The issue arises when I expand a TreeNode with a large number of children (more than 50), causing my application to become unresponsive for several minutes.

Upon investigation, I discovered that the code responsible for the slowdown is the calculation in sun.lwawt.macosx.CAccessibility.getChildrenAndRolesRecursive. After a duration of 2-3 minutes, the application becomes responsive again.

I found a similar bug with the same problem in a JetBrainsRuntime project, which was resolved in this commit. As a result, I was able to resolve my issue by using the JDK jbr_jcef-17.0.7-osx-aarch64-b966.2 from JetBrains.

My request is whether Corretto 17 could implement a similar fix as the one implemented in the JetBrains project. I greatly appreciate any assistance provided.

Platform information

MacBook Pro M1, 2020
OS: macOS Monterey Version 12.5
Version Amazon Correto 17.0.5

Feedback Collection for Corretto-Lilliput

If you have tried the nightly build of Corretto-17 of Lilliput (or any other one - OpenJDK, JDK-tip). Please share your experience, with us in a comment.

Feel free to share as a little or as much as you can, we are mostly looking for:

Reduction of memory utilization
Throughput improvements (or regressions)
Latency improvement (or regressions) at various percentiles
Other metrics changing (positively or negatively)
Did you run under full load at conditions similar to production
Version, and flags used
If you see regressions, do they appear on specific code paths? are you able to share the pattern/sample code?

LTO Binaries

Is your feature request related to a problem?

Performance

Describe a solution you would like

OpenJDK's configure has a link-time-opt feature (--with-jvm-features=link-time-opt) that will engage LTO to hopefully improve performance of produced binaries. Corretto's official binary distributions (produced through its custom Gradle build system) don't enable LTO.

Should it? If not, why?

Describe alternatives you have considered

Leaving things the way they are.

JVM crash: # SIGSEGV (0xb) at pc=0x0000000000000000, pid=1, tid=22

This is a rare crash in a container running a Kotlin GRPC app.
I managed to capture the java_error.log via a
"-XX:ErrorFile=/opt/disco/debug/java_error.log"]

Sadly, it wrote the core to the container filesystem:
# Core dump will be written. Default location: /opt/disco/core.1

I'd love to follow up to this w/ a proper core. In the meantime, I'll post the java_error.log here.

I couldn't immediately find the magic -XX param to write the core to a place where it would be written outside the container. Is there an equivalent -XX:CoreFile arg?
java_error.log

Problems with WildFly 25 and jdk17.0.3_6 (only Windows) - same in Java 8.332

Describe the bug

After Update from 8.342 to 17.0.3 i started my WildFly and it deployed without errors. But when i open my webapp i got this exceptions:

2022-08-09 11:32:38,953 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /opusp/: javax.servlet.ServletException: java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
	at [email protected]//org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:889)
	at [email protected]//org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:818)
	at org.apache.jsp.index_jsp._jspService(index_jsp.java:105)
	at [email protected]//org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at [email protected]//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
	at [email protected]//org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
	at [email protected]//org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
	at [email protected]//org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
	at [email protected]//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
	at [email protected]//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
	at [email protected]//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at [email protected]//io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
	at [email protected]//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
	at [email protected]//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at [email protected]//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.lambda$handleRequest$1(ElytronRunAsHandler.java:68)
	at [email protected]//org.wildfly.security.auth.server.FlexibleIdentityAssociation.runAsFunctionEx(FlexibleIdentityAssociation.java:103)
	at [email protected]//org.wildfly.security.auth.server.Scoped.runAsFunctionEx(Scoped.java:161)
	at [email protected]//org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:73)
	at [email protected]//org.wildfly.elytron.web.undertow.server.ElytronRunAsHandler.handleRequest(ElytronRunAsHandler.java:67)
	at [email protected]//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
	at [email protected]//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:117)
	at [email protected]//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at [email protected]//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at [email protected]//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at [email protected]//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at [email protected]//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at org.wildfly.security.elytron-web.undertow-server-servlet@1.10.0.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at [email protected]//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
	at [email protected]//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:280)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:79)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:134)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:131)
	at [email protected]//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at [email protected]//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
	at [email protected]//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:260)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:79)
	at [email protected]//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:100)
	at [email protected]//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
	at [email protected]//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:852)
	at [email protected]//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
	at [email protected]//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
	at [email protected]//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280)
	at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.xnio.channels.Channels
	at [email protected]//io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:619)
	at [email protected]//io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:497)
	at [email protected]//io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:586)
	at [email protected]//io.undertow.servlet.spec.HttpServletResponseImpl.sendRedirect(HttpServletResponseImpl.java:211)
	at org.apache.jsp.index_jsp._jspService(index_jsp.java:92)
	... 54 more

To Reproduce

WildFly with a war. Loads the page with 8.342. After Update to 17 above error.

Expected behavior

Load the Servlet/WepApp.

Platform information

OS: Windows 10 Pro (21H2)
Version Corretto-17.0.3.6.1

Additional context

Java8-Issue: corretto/corretto-8#383.
I have to set "set "JAVA_OPTS=%JAVA_OPTS% -Djdk.io.File.enableADS" in the Java-Options, then it works.

How are official Corretto Linux binaries built?

From forensic breadcrumbs left in the ELF binaries, it looks like the canonical Linux ELF binaries of Corretto are built from a RedHat flavor Linux distro (possibly RHEL/CentOS 7 based on presence of GCC 4.8). These are then repackaged into .deb archives. (Which is fine: a .deb is a glorified tar archive and just a medium for expressing file installs.)

But if I look at GitHub Actions CI in this repo, I only see references to building on Ubuntu 20.04.

It certainly seems like the official Corretto binaries are built using a different mechanism from the transparent/reproducible GitHub Actions configs in this repo.

Are details of Corretto's official binary building public? If I wanted to reproduce them, how would I go about that?

JVM Crash during C2 Compilation

Describe the bug

During the C2 compilation application crashes. It happens only a couple of times in a day on more than 100 instances

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000000, pid=18002, tid=18040
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.6.10.1 (17.0.6+10) (build 17.0.6+10-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.6.10.1 (17.0.6+10-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000000000
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/runner/server/core.18002)
#
# If you would like to submit a bug report, please visit:
#   https://github.com/corretto/corretto-17/issues/
#

---------------  S U M M A R Y ------------

Host: Intel(R) Xeon(R) Platinum 8375C CPU @ 2.90GHz, 8 cores, 15G, Ubuntu 18.04.6 LTS
Time: Tue Feb  7 11:56:29 2023 UTC elapsed time: 575.014781 seconds (0d 0h 9m 35s)

---------------  T H R E A D  ---------------

Current thread (0x00007f796c102630):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=18040, stack(0x00007f7931bfc000,0x00007f7931cfd000)]


Current CompileTask:
C2: 575014 68221   !   4       kotlinx.coroutines.flow.AbstractFlow::collect (189 bytes)

To Reproduce

Steps and (source) code to reproduce the behavior.
I don't have any method to reproduce the issue; it always happens during the C2 compiler phase.

Expected behavior

A clear and concise description of what you expected to happen.
JVM shouldn't crash during C2 compiler

Platform information

OS: Ubuntu 18.04.6 LTS
JDK version 17.0.6+10-LTS

hs_err_pid18002.log
replay_pid18002.log

JVM crash with EXCEPTION_ACCESS_VIOLATION

Describe the bug

On Windows servers we see intermittent crashes (less than 1% of runs, but happens about once a week)

To Reproduce

We haven't been able to reliably reproduce given the intermittent occurrences.

Expected behavior

JVM not to crash or provide a more specific cause.

Screenshots

N/A

Platform information

OS: Windows Server 2012 R2
Version: Corretto-17.0.3.6.1

Additional context

Some info about our setup that could be relevant... The crashes happen on our CI servers when running unit tests, but it has been a different tests in different modules for each failure. Failures have been in projects with a mix of Java and Kotlin or in pure a pure Kotlin project - we have few pure Java projects. Tests are ran using Gradle.

Attached logs for most recent three instances; seems our CI isn't configured to *.mdmp files i'll configure it to save any future ones.

hs_err_pid2300.log
hs_err_pid1640.log
hs_err_pid9108.log

JVM crash with SIGSEGV

Describe the bug

What: After updating to amazoncorretto:17 we've seen irregular JVM-crashes for a workload with below log. The crash usually happens within the first 5 minutes after starting the workload. Up until the crash, the workload works as expected.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000000000, pid=1, tid=14
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.2.8.1 (17.0.2+8) (build 17.0.2+8-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.2.8.1 (17.0.2+8-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Problematic frame:
# C  0x0000000000000000
#
# Core dump will be written. Default location: //core.1
#
# An error report file with more information is saved as:
# //hs_err_pid1.log
#
# Compiler replay data is saved as:
# //replay_pid1.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/corretto/corretto-17/issues/
#
[error occurred during error reporting (), id 0xb, SIGSEGV (0xb) at pc=0x00007fd7072cb23b]

How often: twice with a period of 7 days in between
Where: Workload runs as a ECS Fargate task
Dumps: None as the dumps were only written to ephemeral storage so far (if that worked as expected)

To Reproduce

No reliable reproduction as this happens very rarely.

Expected behavior

JVM does not crash.
When JVM crashes, it is able to report the error correctly.

Platform information

OS: Amazon Linux 2
Version: Corretto-17.0.2.8.1 (17.0.2+8) (build 17.0.2+8-LTS) (see log above)
Base-image: public.ecr.aws/amazoncorretto/amazoncorretto:17

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process. --> unfortunately not available currently, as this has only been written to ephemeral storage of the fargate task container.

Thank you for considering this report! If there is additional information I can provide to help with resolving this, please do not hesitate to reach out!

JVM dying with unnecessary_acquire error

Describe the bug

When running latest Corretto 17 in Fargate we are seeing the JVM randomly dying with the following error message:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000ffffa7b94894, pid=1, tid=77
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.4.9.1 (17.0.4.1+9) (build 17.0.4.1+9-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.4.9.1 (17.0.4.1+9-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, shenandoah gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x2d5894]  unnecessary_acquire(Node const*)+0x3c
#
# Core dump will be written. Default location: /opt/jslice/core.1
#
# An error report file with more information is saved as:
# /opt/jslice/hs_err_pid1.log

We couldn't get the hs_err_pid log file nor the core dump file, because the container exited before we could save it.

We are running the JVM with the following options java -server -XX:+UseShenandoahGC -XX:+AlwaysPreTouch -XX:InitialRAMPercentage=30.0 -XX:MaxRAMPercentage=50.0 -XX:+DisableExplicitGC

Platform information

Fargate running on Graviton 2 with `amazoncorretto:17` docker image

JVM crash when launching MC 1.19 using Generational ShenandoahGC

Describe the bug

I have ran into this error twice so far, and I have talked to 2 others that also had this issue. It will randomly happen when wandering around in a server. The entire JVM will shutdown and give this log
hs_err_pid84585.log
:

Platform information

OS: Debian 11
Version:

openjdk version "17.0.2" 2022-04-08
OpenJDK Runtime Environment Corretto-17.0.2.8.1 (build 17.0.2+8-Nightly)
OpenJDK 64-Bit Server VM Corretto-17.0.2.8.1 (build 17.0.2+8-Nightly, mixed mode, sharing)

A fatal error has been detected by the Java Runtime Environment: EXCEPTION_ACCESS_VIOLATION (0xc0000005)

Describe the bug

I am working on a desktop application that uses serial communication to retrieve debug data from a device using an Edgeport/1i. When I actuate the button to navigate to a particular feature, the app closes and a log file is generated if, and only if, the Edgeport is plugged into my PC.

To Reproduce

Click on the feature button

Expected behavior

The feature launches and data acquisition should begin.

Platform information

OS: Windows 11
Version "Corretto-17.0.5"

hs_err_pid2388.log

JVM crash with SIGSEGV in C [libc.so.6+0x14b4b1] __strlen_avx2+0x11

our server crashed leaving this behind - I stripped a bit of info away <<>> marks the spots:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f5f185a04b1, pid=3329, tid=3343
#
# JRE version: OpenJDK Runtime Environment Corretto-17.0.0.35.1 (17.0+35) (build 17+35-LTS)
# Java VM: OpenJDK 64-Bit Server VM Corretto-17.0.0.35.1 (17+35-LTS, mixed mode, sharing, tiered, compressed class ptrs, z gc, linux-amd64)
# Problematic frame:
# C  [libc.so.6+0x14b4b1]  __strlen_avx2+0x11
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   https://github.com/corretto/corretto-17/issues/
#

---------------  S U M M A R Y ------------

Command Line: <<<stripped>>> -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -XX:+PrintCommandLineFlags -XX:+DisableExplicitGC -XX:ZCollectionInterval=20 -Xlog:safepoint=info,compilation*,jit*,gc:file=<<<stripped>>>/logs/jit-logging-output.log:time,level,tags:filecount=10,filesize=10M -XX:+PrintCompilation -XX:+SafepointTimeout -XX:SafepointTimeoutDelay=30 -XX:+UseCountedLoopSafepoints -XX:LoopStripMiningIter=10 -Xmx11G -Xms11G -XX:ThreadPriorityPolicy=1 <<<stripped>>>
Host: Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz, 8 cores, 15G, Amazon Linux release 2 (Karoo)
Time: Tue Oct 26 12:51:25 2021 UTC elapsed time: 26381.405019 seconds (0d 7h 19m 41s)

---------------  T H R E A D  ---------------

Current thread (0x00007f5f10089f90):  VMThread "VM Thread" [stack: 0x00007f5ef80e6000,0x00007f5ef81e6000] [id=3343]

Stack: [0x00007f5ef80e6000,0x00007f5ef81e6000],  sp=0x00007f5ef81e3ee8,  free space=1015k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x14b4b1]  __strlen_avx2+0x11
V  [libjvm.so+0x915e84]  jio_fprintf+0x84
V  [libjvm.so+0xaa2fa1]  LogFileStreamOutput::write(LogDecorations const&, char const*)+0xa1
V  [libjvm.so+0xaa20cc]  LogFileOutput::write(LogDecorations const&, char const*)+0x7c
V  [libjvm.so+0xaaf34f]  LogTagSet::vwrite(LogLevel::type, char const*, __va_list_tag*)+0x21f
V  [libjvm.so+0xcf8aaa]  void LogImpl<(LogTag::type)119, (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, (LogTag::type)0>::write<(LogLevel::type)3>(char const*, ...)+0x9a
V  [libjvm.so+0xcf78de]  SafepointTracing::end()+0xae
V  [libjvm.so+0xcf7a48]  SafepointSynchronize::end()+0x148
V  [libjvm.so+0xf8ee4e]  VMThread::inner_execute(VM_Operation*)+0x1ee
V  [libjvm.so+0xf8f10f]  VMThread::run()+0xbf
V  [libjvm.so+0xf0bca2]  Thread::call_run()+0xe2
V  [libjvm.so+0xc44e71]  thread_native_entry(Thread*)+0xe1


siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x000000000000001c

<<<stripped many more details>>>

This happened now once in one of the about 500 servers or so running the same code in different AWS regions over the last week or so.

TarBall for mac is corrupt

Download tar ball
tar xvf it
Go to Contents/Home/bin
./java
Popup appears with corrupt.

Doing the same with pkgutil and pkg appears to work

SIGSEGV core dump fatal error when using latest Couchbase SDK which depends on Netty native transport

Describe the bug

During startup of a java application that attempts to initialize a connection to Couchbase (using Couchbase SDK 3.2.4) which depends on Netty native transport protocol it fails with a core dump. The log file for this core dump is attached.

This java application is utilizing the docker image amazoncorretto:17.0.1-alpine. Please note that we have been able to successfully run this exact same application utilizing adoptopenjdk/openjdk11:x86_64-alpine-jdk-11.0.13_8.

From the stack trace it appears that it's trying to load native code via JNI. It appears to rely on epoll transport which it's failing to load.

I can see the native code assembly in /tmp after attempting startup:

-rw------- 1 cvt_ecs cvt_ecs 89509 Jan 19 14:26 libcom_couchbase_client_core_deps_netty_transport_native_epoll_x86_647469285761372050078.so

It's not clear to us why it's failing to load with corretto while this seems to work with other runtimes. Are we hitting a corretto specific bug? Are we missing a native component in the docker image itself?

To Reproduce

Create a simple java application that utilizes Couchbase SDK 3.2.4 and the corretto docker image amazoncorretto:17.0.1-alpine
Start the application so that it initializes the connection and you should see it fail with the corresponding SIGSEGV and fault.

Expected behavior

I expect the application to startup and function like normal (similar to other images like adoptopenjdk/openjdk11:x86_64-alpine-jdk-11.0.13_8).

Platform information

OS: We originally saw this issue on AWS ECS Amazon Linux 2 but have been able to pull to the docker image down and also reproduce the issue locally on Mac OS running docker. The issue is not specific to the host OS.
Version:

bash-5.1$ java -version
NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
NOTE: Picked up JDK_JAVA_OPTIONS: --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
Picked up JAVA_TOOL_OPTIONS: -XX:+UseContainerSupport
openjdk version "17.0.1" 2021-10-19 LTS
OpenJDK Runtime Environment Corretto-17.0.1.12.1 (build 17.0.1+12-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.1.12.1 (build 17.0.1+12-LTS, mixed mode)

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process
hs_err_pid38.log
.

jdeps --multi-release --print-module-deps fails

Describe the bug

The bug is already described in detail here: https://bugs.openjdk.java.net/browse/JDK-8277165.

In my specific case:

jdeps --multi-release 17 --print-module-deps -cp target/BOOT-INF/lib/*.jar target/CustomerService-0.0.1.jar
Exception in thread "main" java.lang.Error: java.util.concurrent.ExecutionException: com.sun.tools.jdeps.MultiReleaseException
	at jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:271)
	at jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.parse(DependencyFinder.java:133)
	at jdk.jdeps/com.sun.tools.jdeps.DepsAnalyzer.run(DepsAnalyzer.java:129)
	at jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:74)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1047)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:574)
	at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:533)
	at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49)
Caused by: java.util.concurrent.ExecutionException: com.sun.tools.jdeps.MultiReleaseException
	at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
	at jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.waitForTasksCompleted(DependencyFinder.java:267)
	... 7 more
Caused by: com.sun.tools.jdeps.MultiReleaseException
	at jdk.jdeps/com.sun.tools.jdeps.VersionHelper.add(VersionHelper.java:62)
	at jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileReader.readClassFile(ClassFileReader.java:360)
	at jdk.jdeps/com.sun.tools.jdeps.ClassFileReader$JarFileIterator.hasNext(ClassFileReader.java:402)
	at jdk.jdeps/com.sun.tools.jdeps.DependencyFinder.lambda$parse$5(DependencyFinder.java:179)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.lang.Thread.run(Thread.java:833)

To Reproduce

Already described here: https://bugs.openjdk.java.net/browse/JDK-8277165

Expected behavior

jdeps should run without an exception and print out the correct list of module dependencies. Please backport OpenJDK 18 fix.

Platform information

OS: Mac OS X and Amazon Linux 2
Version: Corretto-17.0.2.8.1

[Question] How to install additional packages using apt-get inside amazoncorretto:11

I'm trying to use amazoncorretto:11 as a base image to create an image for my application.

I need to install additional packages in the container using apt-get command.
But with corretto as base image, I'm getting the following error.

 => ERROR [ 3/11] RUN apt-get update && apt-get install -y curl python3-pip                                                                  0.4s
------
 > [ 3/11] RUN apt-get update && apt-get install -y curl python3-pip:
#7 0.336 /bin/sh: apt-get: command not found
------
error: failed to solve: executor failed running [/bin/sh -c apt-get update && apt-get install -y curl python3-pip]: exit code: 127

How can I use apt-get while using corretto as a base image?

17.0.2 not honoring -XX:+ShowCodeDetailsInExceptionMessages for detailed NPE messages

Thank you for taking the time to help improve OpenJDK and Corretto.

If your request concerns a security vulnerability then please report it by email to [email protected] instead of here. (You can find more information regarding security issues at https://aws.amazon.com/security/vulnerability-reporting/.)

Otherwise, if your issue concerns OpenJDK and is not specific to Corretto we ask that you raise it to the OpenJDK community. Depending on your contributor status for OpenJDK, please use the JDK bug system or the appropriate mailing list for the given problem area or update project.

If your issue is specific to Corretto, then you are in the right place. Please proceed with the following.

Describe the bug

I start my application with

java -XX:+ShowCodeDetailsInExceptionMessages -jar jar.jar

My code has a problem and processing is failing with:

java.lang.NullPointerException: null

Expected behavior

per https://openjdk.java.net/jeps/358 I expected to get a helpful hint where my NPE is.

Platform information

OS: Amazon Linux 2
Docker image: amazoncorretto:17.0.2

Missing vcruntime140_1.dll in bin directory

Is your feature request related to a problem?

The open-jdk windows build inlcudes the vcruntime140_1.dll in its bin directory. This dll is needed by open jfx (more precisely the glass.dll). The Amzon corretto windows build does not bundle this dll and made it necessary to get the dll from another source (if I am correct e.g. by installing the right C++ redistributables or getting it from the open jdk).
Its a small but annoying disadvatage of using corretto instead of open jdk.

Describe a solution you would like

Please bundle vcruntime140_1.dll with the windows build of Amazon Corretto

Europe/Amsterdam timezone is now broken due to error in tz update 2022c.

This is the last version with the correct tz info for Europe/Amsterdam:

corretto-17/make/data/tzdata/europe

Line 2215 in 9068185

0:20 Neth +0020/+0120 1940 May 16 0:00

The next commit basically says 'amsterdam is exactly like brussels'. Amongst other things, it changes the moment when Europe/Amsterdam joins the modern age, timewise, from the correct May 16th 1940, to the incorrect May 20th 1940. (It's correct for Brussels; it's not correct for Amsterdam. Nazi germany changing timezones on countries they occupied, and said countries not reverting to their pre-war state after being liberated, explains these dates).

I'm not familiar enough with the rules about timezone stuff to know if this is an error in corretto or an error in tzdata. However, the upshot is rather drastic. Code like this:

Date d = new Date(40, 2, 1); // cruddy old broken API, I know
System.out.println(d.getTime()); // wrong answer!

is broken for any date before may 20th (not just between may 16th and may 20th 1940). At least, it's clearly wrong in that range, and before that range, it's inconsistent with prior versions. I can run this code:

Date d = new Date(37, 8, 2);
System.out.println(d.getTime());

And when I upgrade/downgrade between Corretto v17.0.4.9-1 and Corretto v17.0.5.8-1, this prints different numbers, without changing the TZ at all (it's set to Europe/Amsterdam on this machine, with the RTC on UTC, on ubuntu running on ec2).

I believe v17.0.4.9-1 gives the right answer, and v17.0.5.8-1 gives the wrong answer.

This has far reaching deleterious effects: for example, DATE columns in h2 now report the wrong date (off by a day) for any date prior to may 20th, 1940. Evidently because h2 stores millis and not y/m/d for some reason. Any code anywhere that flips between DMY and milli-based storage mechanisms will flat out break for anything prior to may 20th 1940, even when consistently applying the Europe/Amsterdam timezone.

Please advise if the tzdata in corretto is just copied from elsewhere, and that therefore I should be filing this bug elsewhere.

In the mean time, for all affected: Downgrading is the only way I can fix this, if you want e.g. h2 databases to not be unfixably broken if they are storing dates prior to May 20th 1940 and your server is setup in Europe/Amsterdam zone.

Generational Shenandoah non promoting objects to Old Gen

Describe the bug

Running Apache Geode (In memory DB) with Amazon Coretto early builds with Generational Shenandoah (amazon-corretto-17.0.1.12.1-06f6f03f6a-linux-x64.tar.gz).

Apache Geode is an in memory DB, and I am running another program to populate data in the DB

Using JConsole is trivial to observe that Old Generation is completely empty and GC not able to promote objects to Old Gen, even after many minutes and keep populating Geode with many many thousands of entries and after many Young Gen collections.

Only when Young Gen is almost exhausted a very minor portion of referenced objects look to be promoted to Old Gen.

Geode Server JVM options can be seen in
/home/eceejcr/Downloads/amazon-corretto-17.0.1.12.1-linux-x64/bin/java -server -classpath /home/eceejcr/Development/geode/apache-geode-1.14.0/lib/geode-core-1.14.0.jar:/home/eceejcr/Development/geode/apache-geode-1.14.0/lib/geode-dependencies.jar -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=127.0.0.1[10334] -Dgemfire.use-cluster-configuration=true -Xmx6144m -Xms6144m -Xmn1024m -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:InitialTenuringThreshold=5 -Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=20M --add-opens java.base/java.nio=ALL-UNNAMED -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806 org.apache.geode.distributed.ServerLauncher start server2 --server-port=0

I know that heuristics are missing in generational shenandoah, so maybe my JVM options are not correct

To Reproduce

Install Apache Geode, and try to populate it

Expected behavior

Objects promotion to old gen to happen gradually like with any other generational collector like G1

Screenshots

Platform information

OS: manjaro
Version : corretto-17.0.1.12.1-linux-x64 early build with generational shenandoah

RPM package for Generic Linux should provide "jre-17" capability to match OpenJDK packages

Describe the bug

The RPM Package (generic Linux) is not configured to provide "jre-17". As a result, packages that require this will not install as they are missing a dependency. If available, a different JRE will be installed automatically from a configured OS repository over Corretto.

To Reproduce

Download and install the Amazon Corretto RPM on an OS other than Amazon Linux 2, such as CentOS 7 or Rocky 8.
Identify an RPM package that requires "jre-17" and attempt to install it using rpm or yum. For me, this is Neo4j Server, but other packages might exist with this dependancy.
Install will either fail with a dependency issue or another java-17 (such as java-17-openjdk) will be installed as a dependency.

Expected behavior

RPM package installs normally, without issue.

Screenshots

$ sudo rpm -i cypher-shell.rpm neo4j.rpm
error: Failed dependencies:
	jre-17 >= 17 is needed by cypher-shell-5.1.0-1.noarch
	jre-17 is needed by neo4j-5.1.0-1.noarch

Platform information

OS: CentOS 7, Rocky 8
Version:  Corretto-17.0.5.8.1 (build 17.0.5+8-LTS)

$ java --version
openjdk 17.0.5 2022-10-18 LTS
OpenJDK Runtime Environment Corretto-17.0.5.8.1 (build 17.0.5+8-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.5.8.1 (build 17.0.5+8-LTS, mixed mode, sharing)

Additional context

I'm aware that there exists an RPM option to disable dependency checks (--nodeps). This is a workaround, but the package should be updated to include the correct "provides" capabilities to match the official OpenJDK package.

From Rocky 8:

$ rpm -q --provides java-17-openjdk
java-17 = 1:17.0.5.0.8-2.el8_6
java-17-openjdk = 1:17.0.5.0.8-2.el8_6
java-17-openjdk(x86-64) = 1:17.0.5.0.8-2.el8_6
jre-17 = 1:17.0.5.0.8-2.el8_6
jre-17-openjdk = 1:17.0.5.0.8-2.el8_6

Amazon Corretto RPM package should include these for optimal compatability.

Shenandoah GC crash on minecraft java edition

Describe the bug

Running Minecraft java edition server with shenandoah garbage collector with corretto 17 crashes, usually within an hour of running under load.

To Reproduce

run minecraft java edition on c6g.large, it will work indefinitely until a player logs in and plays, then a crash in the GC always occurs.

Expected behavior

It shouldn't crash

Platform information

OS: AL2 on an EC2 c6g.large
Version:
    openjdk 17.0.2 2022-04-08
   OpenJDK Runtime Environment Corretto-17.0.2.8.1 (build 17.0.2+8-Nightly)
    OpenJDK 64-Bit Server VM Corretto-17.0.2.8.1 (build 17.0.2+8-Nightly, mixed mode, sharing)

Additional context

see attached log

hs_err_pid6150.log

Corretto for BSD

Is it possible to have Corretto for BSD operating system?

I am shifting from Linux to using BSD as server operating system and would require Coretto.

FreeBSD already has OpenJDK ported to it.

When will Corretto be available for BSD operating systems or specifically FreeBSD and OpenBSD?

NullPointerException in java.util.Spliterator.getExactSizeIfKnown(): "this" is null

I have raised this in an internal AWS support ticket where I was encouraged to also create a ticket here.

I'm running a Java AWS Lambda function using a custom Amazon Corretto 17 Docker runtime. During execution I got an unexpected NullPointerException in java.util.Spliterator.estimateSize() because "this" is null. The characteristics of the exception indicates that this issue is related to the runtime or JDK rather than the application code.

Describe the bug

The failing invocation resulted in the following stack trace:

java.lang.NullPointerException: Cannot invoke "java.util.Spliterator.estimateSize()" because "this" is null
at java.base/java.util.Spliterator.getExactSizeIfKnown(Spliterator.java:414) ~[na:na]
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:508) ~[na:na]
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[na:na]
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[na:na]
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[na:na]
at java.base/java.util.stream.ReferencePipeline.reduce(ReferencePipeline.java:662) ~[na:na]
at java.base/java.util.stream.ReferencePipeline.min(ReferencePipeline.java:703) ~[na:na]
at org.company.name.SomeClass1.someMethod1(SomeClass1.java:50) ~[lambda1.jar:na]
...
at org.company.name.SomeClass2.someMethod2(SomeClass2.java:82) ~[lambda1.jar:na]
at org.company.name.SomeClass3.lambda$someMethod3$1(SomeClass3.java:61) ~[lambda1.jar:na]
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[na:na]
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) ~[na:na]
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[na:na]
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[na:na]
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[na:na]
at java.base/java.util.stream.ReduceOps$ReduceTask.doLeaf(ReduceOps.java:960) ~[na:na]
at java.base/java.util.stream.ReduceOps$ReduceTask.doLeaf(ReduceOps.java:934) ~[na:na]
at java.base/java.util.stream.AbstractTask.compute(AbstractTask.java:327) ~[na:na]
at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:754) ~[na:na]
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[na:na]
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[na:na]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[na:na]
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[na:na]
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[na:na]

The code generating the error is calling java.util.stream.Stream#min:


    private static final List<SomeClass3> LIST_1 = Arrays.asList( // java.util.Arrays.ArrayList
           new SomeClass3(1.0, 1.0), <6 more entries>, new SomeClass3(POSITIVE_INFINITY, 10.0));

    private static final List<SomeClass3> LIST_2 = Arrays.asList( // java.util.Arrays.ArrayList
           new SomeClass3(1.0, 1.0), <4 more entries>, new SomeClass3(POSITIVE_INFINITY, 10.0));

    public double someMethod1(double value1, double value2) {

        List<SomeClass3> someClass3StaticConstantList;
        if (someCondition(value2)) {
            someClass3StaticConstantList = LIST_1;
        } else {
            someClass3StaticConstantList = LIST_2;
        }

        SomeClass3 object = someClass3StaticConstantList.stream() // 6 or 8 elements
            .filter(l -> someFilter(l, value1, value2))
            .min(Comparator.comparing(SomeClass3::getDouble)) // SomeClass1.java:50, getDouble returns primitive double
            .orElse(DEFAULT_OBJECT);

        return object.getDouble();
    }

someMethod1 is invoked by a parallel stream:

    
    Map<String, ResultClass> calculatedResults = someArrayList.stream() // 920 elements
        .parallel()
        .filter(item -> someFilter(item))
        .map(item -> Maps.immutableEntry(
            item.getId(),
            someMethod2(item))) // SomeClass3.java:61, Method that invokes someMethod1
        .filter(entry -> entry.getValue() != null)
        .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue)); // SomeClass3.java:63

To Reproduce

Unable to reproduce. Retriggering the same AWS Lambda function with the same input resulted in no error.

Expected behavior

No NullPointerException should be thrown by java.util.Spliterator.getExactSizeIfKnown(). "this" should never be null.

Platform information

  Lambda Function Memory: 10240 MB
  Lambda Function Base Image: amazoncorretto:17.0.6-al2 
  Lambda Function Java Version: openjdk 17.0.6 2023-01-17 LTS OpenJDK Runtime Environment Corretto-17.0.6.10.1 (build 17.0.6+10-LTS) OpenJDK 64-Bit Server VM Corretto-17.0.6.10.1 (build 17.0.6+10-LTS, mixed mode, sharing)

Amazon Linux 2 package missing

Will there be an Amazon Linux 2 package for Corretto 17 similar to the one for Corretto 11 (java-11-amazon-corretto-headless.x86_64)?

Fix auto-version update when upstream is missing tags

OpenJDK/jdk17u tags for jdk-17.0.2+XX are not being seen by the workflow, so when it tries to find the build number is is getting "" and then updates the version.txt file incorrectly. When the expected tags are not found or the version is being downgraded, the script should fail without updating the file.

Specjbb hangs with ShenandoahGCMode=generational

Describe the bug

SpecJBB 2015 Composite or Backend in Multi hangs after first 15-20 min of the workload.

To Reproduce

Example command line:

java -server -XX:+PrintFlagsFinal -Xnoclassgc -XX:-UseAdaptiveSizePolicy -XX:+AlwaysPreTouch -XX:-UsePerfData -XX:-UseNUMA -XX:-UseNUMAInterleaving -XX:InlineSmallCode=20k -XX:CompileThreshold=1000 -XX:+AvoidUnalignedAccesses -XX:+UseSIMDForMemoryOps -XX:-UseFPUForSpilling -XX:-SegmentedCodeCache -XX:MaxInlineLevel=15 -Xmx81920m -Xms81920m -Xmn1024m -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -Xlog:gc=debug,heap*=debug,phases*=debug,gc+age=debug:Composite.gc.log -Dspecjbb.controller.rtcurve.warmup.step=0.7 -Dspecjbb.forkjoin.workers.Tier1=100 -Dspecjbb.forkjoin.workers.Tier2=1 -Dspecjbb.forkjoin.workers.Tier3=16 -Dspecjbb.customerDriver.threads=64 -Dsecjbb.heartbeat.threshold=900000 -jar specjbb2015.jar -m COMPOSITE

Expected behavior

The application continue to work and print logs, then terminates after ~2 hrs.

Platform information

OS: Red Hat Enterprise Linux, 8.3 (Ootpa)
Version:  Corretto-17, generational-shenandoah branch, e5f77a070fce76a9547340128b3fef3e97c6a082

Additional context

HW: aarch64, Graviton2 (m6g.metal)
GCC: 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)

Put the version number in the download file name.

For example JDK 17 just says "17" for example which means I needed to hunt around to find it was "17.0.3.6.1".

So instead of (for macOS):

https://corretto.aws/downloads/latest/amazon-corretto-17-x64-macos-jdk.pkg

This:

https://corretto.aws/downloads/latest/amazon-corretto-17.0.3.6.1-x64-macos-jdk.pkg

Regression related to JDK-8246094: [macos] Sound Recording and playback is not working

Due to a bug in the signing and notarization process for Corretto, the updated entitlements from JDK-8246094 are not being applied properly. This results in Corretto for macos being unable to prompt the user for access to the microphone, and prevents users from recording sound.

While we address this issue, Corretto 17 for macos will remain in EA / preview.
Once this issue is resolved, we will release Corretto 17 for macos as GA.

Alpine repository returns 403 Forbidden

Trying to install packages from it after following the instructions:

WARNING: Ignoring https://apk.corretto.aws/: Permission denied

Testing it with curl:

# curl -vO https://apk.corretto.aws/APKINDEX.tar.gz
Trying 13.225.0.116...
* TCP_NODELAY set
* Connected to apk.corretto.aws (13.225.0.116) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [230 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [91 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4945 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=corretto.aws
*  start date: Sep 23 00:00:00 2021 GMT
*  expire date: Oct 22 23:59:59 2022 GMT
*  subjectAltName: host "apk.corretto.aws" matched cert's "*.corretto.aws"
*  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
*  SSL certificate verify ok.
> GET /APKINDEX.tar.gz HTTP/1.1
> Host: apk.corretto.aws
> User-Agent: curl/7.64.1
> Accept: */*
> 
< HTTP/1.1 403 Forbidden
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Thu, 07 Oct 2021 17:33:40 GMT
< Server: AmazonS3
< X-Edge-Origin-Shield-Skipped: 0
< X-Cache: Error from cloudfront
< Via: 1.1 1098c68725f26a6e79b4565dded7de39.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: SIN52-C2
< X-Amz-Cf-Id: CRAT5IG9o5-Q4XDAjUj4Xw3EI4m2RH-AiyeHngmxltkfvNINdmXlnw==
< 
{ [249 bytes data]
100   243    0   243    0     0    214      0 --:--:--  0:00:01 --:--:--   214
* Connection #0 to host apk.corretto.aws left intact
* Closing connection 0

Minecraft 1.19.4 with java-17 crashes way too much.

Hello,
I've been running the Minecraft Server since 2019 with absolutely no issues. However since I updated to java 17 I only ran into issues, sometimes even losing hours of progress with corrupted chunks. Minecraft was always my favorite game, but with all those crashes I can't take it anymore. How do other servers run 24/7 with no issues? I'm not sure if this is my OS, maybe? Or if its a missing dependency or just something else. I have very little knowledge in Java and I really need help.

I started PaperSpigot 1.19.4 and It may run for few hours and crash then, or It crashes just in a few seconds.

I was expecting to run it in a Linux-screen with no Issues, (I did this back in 1.18) and I had no issues, yes Corretto reduces the crashed a lot, but I would like to have a crash-free experience, like I did before. If there's no solution, then my last option would be to move back to Windows, or virtualiter it differently. I also have a crash file "_usr_lib_jvm_java-17-amazon-corretto_bin_java.1000.crash" but its 334 MB big I could give you that too, but GitHub has a limit of 25 MB at least here. If possible, I would like to stay on Ubuntu, because going back to Windows would be the very last option that I would need to take.

Take a look at all the logs that I provided, and if you need more information I can surely hand out. Any help would be really appreciated. :)

regards Conrad

Platform information

My OS is: Ubuntu 22.04.06 LTS 64 bit

Java information

openjdk version "17.0.7" 2023-04-18 LTS
OpenJDK Runtime Environment Corretto-17.0.7.7.1 (build 17.0.7+7-LTS)
OpenJDK 64-Bit Server VM Corretto-17.0.7.7.1 (build 17.0.7+7-LTS, mixed mode, sharing

replay_pid368908.log
hs_err_pid368908.log

Corretto Downloads

I don‘t know which repository is the right one to report this issue. I chose this one because I feel that 17 should get most attention these days, since it is the latest LTS. However, this issue doesn‘t belong here.

How does https://corretto.github.io/corretto-downloads/ come into existence? The https://corretto.github.io/ page gives a 404, and following “View on GitHub” link at the top points to https://github.com/corretto/corretto-downloads also resulting in a 404. Lastly the “CONTRIBUTING” link https://corretto.github.io/corretto-downloads/CONTRIBUTING.md#security-issue-notifications results in a download of the generic AWS contributing file, but it does not actually go to a web page (and the linked fragment).

Then there is the https://corretto.github.io/corretto-downloads/latest_links/indexmap_with_checksum.json link. Given all the previous questions one has to question if it is actually genuine. How is it generated? Can we trust the checksums? Or is it that they are easily compromised if someone is able to change what we find at https://corretto.aws/ (where all the referenced files are we can download)?

I hope it is possible to resurrect https://github.com/corretto/corretto-downloads, or create it if it never existed, and to make the process behind all of this transparent. This would greatly increase trust.

Last, but not least, if would be great to have a https://corretto.github.io/available-releases.json similar to https://api.adoptium.net/v3/info/available_releases that allows dynamic resolution of the latest versions, including designation of LTS and non-LTS releases. Something like the Adoptium API would generally be a good thing to have, but that is not easily built with GitHub pages.

Offer cryptographic signatures of downloadable artefacts

If your issue is specific to Corretto, then you are in the right place. Please proceed with the following.

Describe the bug

Most Amazon Corretto 17 Downloads from Github can only be verifyed by MD5, cryptographic signature files (*.sig) are only available for some downloads.

To Reproduce

Visit https://github.com/corretto/corretto-17/releases

Expected behavior

For every binary artefact there exists at least a downloadable and easily verifyable cryptographically valid checksum. Better even a signature file that can be verified by a published cryptographical key.

EXCEPTION_ACCESS_VIOLATION both for G1 and ParallelGC garbage collectors

It appears that the same Amazon Corretto 11 issue still occurs in Corretto 17:
corretto/corretto-11#102

Support for release Alpine aarch64 packages

As reported at corretto/corretto-docker#46

It seems that no packages for Alpine(aarch64) are released. As I see a step to enable this would to include in the release process such step to publish the alpine package. Only then docker images would be possible.

Not sure in which project the release and publish is addressed but it seems to me that here would be a good start.

Is your feature request related to a problem?

During the release/publish process we would require a new step for publishing aarch64 for alpine https://apk.corretto.aws

Describe a solution you would like

Include in the release/publish steps a new package for alpine with aarch64 for https://apk.corretto.aws

Describe alternatives you have considered

Please provide a clear and concise description
of any alternative solutions or features you have considered.

Additional context

Add any other context or screenshots about the feature request here.

Several tier1 test failed assertion in ShenandoahYoungGenMemoryPool::get_memory_usage()

Describe the bug

# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/zhengyu/ws/corretto-17/src/hotspot/share/gc/shenandoah/shenandoahMemoryPool.cpp:78), pid=2135199, tid=2135266
# assert(initial <= max) failed: initial: 805306368, max: 268435456
#

To Reproduce

Run tier test with generational Shenandoah:
make CONF=linux-x86_64-server-fastdebug run-test TEST=tier1 TEST_VM_OPTS=-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

Additional contex

hs_err_pid2134734.log

Release timeline

What is your release timeline? When do you plan to do a new release?

Looking at the latest releases you do a release about every 3 months.

The last release is 17.0.7.7.1, released on 2023-04-17, which contains some vulnerabilities which are fixed upstream for example https://alas.aws.amazon.com/cve/json/v1/CVE-2023-21930.json

Dynamic linking zlib for Linux

Seeking for feedback

Let us know if you have concerns on this change and how we can improve.

Changes

Corretto now uses system zlib rather than bundled zlib.

In the past, Corretto would bundle zlib (use libz.so built from the zlib bundled in JDK source), for linux except for AL, code. Howver, OpenJDK uses system (use libz.so installed in system or passed in LD_LIBRARY_PATH) for linux by default. code. We made zlib in Corretto as bundled only for historical reason. In order to have the parity, we should make it dynamic linking for all linux platforms.

Keep bundled for Windows as Windows doesn't have zlib out of box. Also keep mac as bundled for https://bugs.openjdk.org/browse/JDK-8286623.

User experience

Users are not expected to make any code change or observe behavior differences. Under the hood, instead of using the libz.so built from Corretto source, now Corretto will rely on libz.so on the system or in the LD_LIBRARY_PATH if it is set. libz.so is a low level library that majority of the systems have out of box (CentOS, Ubuntu, alpine etc.)

With this change, you can use a different libz.so rather than stick with the bundled zlib. You can pass the library location to LD_LIBRARY_PATH: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<libz.so path>. You can then verify if the path set successfully via ldconfig -p | grep libz.

Target Release Date

The code enabling zlib dynamic linking has already been pushed to Corretto source. It will be published in our next quarterly release (2023-07-18).

In the meantime, you can download our latest nightly builds to try it out: https://downloads.corretto.aws/#/downloads?build=nightly

Make Package 'java-17-amazon-corretto-headless' available in https://yum.corretto.aws/

Is your feature request related to a problem?

I would like to use the package 'java-17-amazon-corretto-headless' which is available in the Amazon Linux 2 Repositories (see here), but is not available in https://yum.corretto.aws/ (repository for RPM based Linuxes).

The package is very interesting to use in a container and thus should be also available in containers for "RPM-based" Linuxes. It is smaller than a JDK and does not contain irrelevant parts for running a Java application. For example, one does not need a java compiler to run a Java application.

Describe a solution you would like

Please provide the package 'java-17-amazon-corretto-headless' in https://yum.corretto.aws/ , so I can install it using

yum install -y java-17-amazon-corretto-headless

Describe alternatives you have considered

I have not seen any alternatives. Amazon Linux 2 is for this use case unfortunately not possible at the moment.

Additional context

Corretto 17.0.4.8.1 Mac .pkg installers

We identified a last-minute issue in the macOS .pkg installers for Corretto 17.0.4.8.1 and they were not published with the rest of this quarter's updates. We expect to publish the updated packages shortly.

In the meantime, for users who need the updates immediately, the macOS .tar.gz file is working as expected. Decompressing its contents into /Library/Java/JavaVirtualMachines of your Mac (and replacing the previous version if it's there) will do the same as the installer package.

jvm crashed

Describe the bug

Unexpected sudden jvm crash

To Reproduce

Unable to reproduce stably after the crash. When the error is reported, i'm writing an error-info json in an HttpResponse object in an token filter, but the error message is about the C code of opencv, guessing it may be an accidental event.
and the code repo is javaLab (now is private, because it is part of my semester assignments, it is inconvenient to make it public before grading, and it will be public in 2023.July——if any other need it)

Expected behavior

normal response to http request

Screenshots

（i'm sorry.I just took this situation as "wow I met a jvm crash" to tell my friends before ,and re-run the program in idea fastly, so I haven't left detailed information. It is only issued here because of the prompt text of the screenshot here）

Platform information

Amazon Corretto version 17.0.5
windows 10 19045.3086

Additional context

just report that, but not need to solve that, thanks.

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process.
here: hs_err_pid56196.log

Test Issue, Please Ignore

Thank you for taking the time to help improve OpenJDK and Corretto.

If your issue is specific to Corretto, then you are in the right place. Please proceed with the following.

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps and (source) code to reproduce the behavior.

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Platform information

OS: [e.g. Amazon Linux 2]
Version [e.g. "Corretto-15.0.1.9.1" (output from "java -version")]

Additional context

Add any other context about the problem here.

For VM crashes, please attach the error report file. By default the file name is hs_err_pidpid.log, where pid is the process ID of the process.

Is there any plan to support Apple Arch M1 for Corretto 17?

Hi,

I'm currently using azul-17 native build for M1 and I'd like to test the corretto-17 native version for M1 as well.

On the Intel arch, I can see corretto-17 performing better than azul-17 and I'd like to test if the corretto-17 for M1 will be better than azul-17 (for M1) as well.

Is there any plan to support Apple Arch M1 for Corretto 17? do you have any planned release date?

Best
E

If there will be a build of Generational-Shenandoah for windows？

Hi, I'm very interested in generational-Shenandoah and would like to evaluate it on Windows Platform.
I know there are pre-compiled builds on https://builds.shipilev.net/openjdk-shenandoah-jdk/, but JDK19 is too new that I can't run the project easily.
So if there will be a generational-shenandoah corretto-17 build for windows in the future? :D

Only availableProcessors() 1 exposed in version 17.0.4.1

hello.
I am running a java service by allocating cpu resources of 1000 millicores or less in EKS.

In the 17.0.4.1 version of corretto-17, java's availableProcessors value only exposes 1. (The number of cpus in the node is 4 cores.)
After changing the version of the base image to corretto-17.0.7, it is exposed as 4 cores as expected.

Corretto team statement on CVE-2021-44228 (Log4j remote code execution)

A high-severity security issue within Log4j2 was recently disclosed publicly (see https://nvd.nist.gov/vuln/detail/CVE-2021-44228 for more details). Anyone using Log4j2 should upgrade to version 2.15, which addresses this issue. Log4j2 versions older than 2.15 should be considered affected regardless of the JDK distribution or version used.

It has been reported that using Log4j2 on JDKs after 8u121 or 8u191 (including JDK 11 and later) mitigates the issue but this is only a partial mitigation. The only comprehensive solution is to upgrade Log4j2 to 2.15.

Information about Corretto 17.0.4

We identified an issue with systems using Amazon Corretto 17.0.4 (July release). This happens in servers using 17.0.4 and fail within C2 compilation of sun.security.ssl.SSLEngineInputRecord::decodeInputRecord.This issue is tracked upstream JBS - JDK-8292260. The release updates are in progress and will be communicated once complete.

A few tier1 tests fail with generational mode

Describe the bug

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/home/zhengyu/ws/corretto-17/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp:214), pid=3918956, tid=3918961
# assert(result != __null) failed: Allocation must succeed: free 5440, actual 5440
#
# JRE version: OpenJDK Runtime Environment (17.0.1) (fastdebug build 17.0.1-internal+0-adhoc.zhengyu.corretto-17)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 17.0.1-internal+0-adhoc.zhengyu.corretto-17, mixed mode, tiered, compressed oops, compressed c lass ptrs, shenandoah gc, linux-amd64)
# Problematic frame:
# V [libjvm.so+0x17ad2be] ShenandoahFreeSet::try_allocate_in(ShenandoahHeapRegion*, ShenandoahAllocRequest&, bool&)+0x161e
#

To Reproduce

make CONF=linux-x86_64-server-fastdebug run-test TEST=tier1 TEST_VM_OPTS=-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

Platform information

OS: [Ubuntu]
Version [20.04.3 LTS (Focal Fossa)]

Additional context

Failed tests:

gc/shenandoah/mxbeans/TestPauseNotifications.java
gc/shenandoah/mxbeans/TestChurnNotifications.java
jdk/javadoc/tool/VerifyLocale
javadoc/doclet/testNestedClasses/TestNestedClasses
tools/javac/classfiles/attributes/annotations/RuntimeAnnotationsForTopLevelClassTest

hs_err_pid3918956.log