Master is merged

I’ve merged the Java 11 changes to the master branch. To summarize: Toolchains are no longer required. Java11 (or later?) is required to build and run. However, I have only tried with Java 11. Log4j-api and log4j-plugins are JPMS modules. Log4j-core will be attacked next. We will want to review

Re: Please do not commit to log4j2 master - but review this PR.

I was able to fix the OSGi tests simply by upgrading the Maven Bundle Plugin. The Warning message coming from the compiler plugin was because the module-info.java file had a requires transitive org.osgi.core and OSGi core is not a JPMS module. But that really isn’t correct since JPMS and OSGi do

Re: Please do not commit to log4j2 master - but review this PR.

The maven verify error is something that affects the master branch too. Something to do with snapshots and depending on them inter-module. I don’t know enough about maven to explain why, but some modules require other modules to have been installed and not just packaged. On Fri, Apr 2, 2021 at 17:

Re: Please do not commit to log4j2 master - but review this PR.

Well, log4j-api, log4j-plugins and log4j-core each have unit tests and test classes that are used by other log4j-modules. Because log4j-api and log4j-plugins are JPMS modules the unit tests need to a) either be in a different package or b) have a module-info.java that essentially extends the re

Re: Garbage Free Precise Time

I just tried adding logic to call SystemClock.init() 100,000 times. It made no difference. The GC test still fails. Ralph > On Apr 2, 2021, at 7:18 AM, Carter Kozak wrote: > > Escape analysis can take quite a few iterations to take effect, perhaps we > need a few more tens of thousands of war

Re: Please do not commit to log4j2 master - but review this PR.

Great work Ralph! Your change set marks an important milestone in Log4j development. Thanks so much! `./mvnw verify` fails for me while compiling the 2nd module, log4j-api: `error: module not found: org.osgi.core`. Any ideas? This said `./mvnw package` succeeds for me, hence all(?) tests pass. $

Re: Garbage Free Precise Time

Escape analysis can take quite a few iterations to take effect, perhaps we need a few more tens of thousands of warmup cycles? Admittedly I haven't taken a look at the failures yet and there's a great deal of subtlety around this. I can try to take a closer look later, unfortunately I've been ov

Re: Garbage Free Precise Time

Looking at the source repo I don’t see anything that changed after support for the higher precision was added. Ralph > On Apr 2, 2021, at 12:44 AM, Ralph Goers wrote: > > Yes, I was just thinking that. But if there was a bug fix along the way that > added a single line of code that could now

Re: Garbage Free Precise Time

Yes, I was just thinking that. But if there was a bug fix along the way that added a single line of code that could now be causing the code not to be inlined. Ralph > On Apr 2, 2021, at 12:38 AM, Remko Popma wrote: > > On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers > wrote: > >> I will take a l

Re: Garbage Free Precise Time

On Fri, Apr 2, 2021 at 4:26 PM Ralph Goers wrote: > I will take a look at the link. What you are saying makes sense to a > degree. However, the new is actually performed in Instant.create() which is > 2 levels down in the call stack. Without having read the link I would > wonder if that qualifies

OpenJDK 17 Early Access build 16 is now available

Hi Ralph, *OpenJDK 17 Early Access build 16 is now available at **http://jdk.java.net/17* * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception

Re: Garbage Free Precise Time

I should also add that I tested with Amazon Correto openjdk version "11.0.10" 2021-01-19 LTS OpenJDK Runtime Environment Corretto-11.0.10.9.1 (build 11.0.10+9-LTS) OpenJDK 64-Bit Server VM Corretto-11.0.10.9.1 (build 11.0.10+9-LTS, mixed mode) This is what my employer has decided to use since Ado

Re: Garbage Free Precise Time

I will take a look at the link. What you are saying makes sense to a degree. However, the new is actually performed in Instant.create() which is 2 levels down in the call stack. Without having read the link I would wonder if that qualifies. Ralph > On Apr 2, 2021, at 12:00 AM, Remko Popma wro

Re: Garbage Free Precise Time

That isn’t the case when I ran it with Java 11 and the latest version of the allocation tool. Virtually everything failed since almost everything creates a timestamp. I would suggest you checkout the master-java11 branch, uncomment the stuff in the SystemClock class and try it yourself. Ralph

Re: Garbage Free Precise Time

My understanding is that PreciseClock is garbage-free because the JVM does escape analysis. Here is the relevant code: public void init(MutableInstant mutableInstant) { Instant instant = java.time.Clock.systemUTC().instant(); mutableInstant.initFromEpochSecond(instant.getEpochSecond(), ins