Non deterministic compile results with lamda numbering

[laeubi]

In PDE we are experiencing a build instability with the class BundleLauncherHelper according to the logs the numbering of lamdas is different compared to those on the baseline, I have captured a compile log that shows the differences and has compile logs with exact classpath and compiler options here: compare.zip

The textcompare shows that only the numbering is different here, please note that the baseline seem not contain any lambda$0 but starting with lambda$1 immediately:

I can't reproduce this locally and even on the CI instance the behavior varies between builds where none are actually changing that bundle.

[iloveeclipse]

This is a known issue with non-deterministic lambda numbering, depending on class build order. There was a bugzilla about it (for sure) and may be also github issue, I haven't checked it. So basically lambda numbers are given by the order in which that lambda is resolved while processing classes by the compiler, and in some cases lambdas in one class may be resolved "earlier" and so get a different number.

[laeubi]

I can't say I understand anything about how lambda handling works, but can't the numbering use the order in wich it encounters the lamda in the source code? Can we do something to help the compiler, e.g. sort source files by name? So basically the order of this list influences lamda numbers:

<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/BundleLauncherHelper.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/JUnitLaunchConfigurationDelegate.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/ILaunchingPreferenceConstants.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchConfigurationListener.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/RequirementHelper.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/IPDEConstants.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/PDESourcePathProvider.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchPluginValidator.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/PreferenceInitializer.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/PDEMigrationDelegate.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchConfigurationHelper.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/ProductValidationOperation.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/PDELaunchingPlugin.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/EquinoxInitializer.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/EquinoxLaunchConfiguration.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/PDEMessages.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/OSGiLaunchConfigurationDelegate.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/OSGiMigrationDelegate.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchArgumentsHelper.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LauncherUtils.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/IPDELauncherConstants.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchListener.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/OSGiLaunchConfigurationInitializer.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/OSGiFrameworkManager.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/sourcelookup/PDESourceLookupDirector.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/sourcelookup/PDESourceLookupQuery.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/LaunchValidationOperation.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/AbstractPDELaunchConfiguration.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/launching/EclipseApplicationLaunchConfiguration.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/EclipsePluginValidationOperation.java"/>
<argument value="/home/jenkins/agent/workspace/eclipse.pde_master/ui/org.eclipse.pde.launching/src/org/eclipse/pde/internal/launching/launcher/VMHelper.java"/>

or maybe ECJ can sort them internally (does order of class file names matter for compilation)?

[iloveeclipse]

As said, it's not trivial, please check bugzilla. I must have reported it for jdt or at least commented on it.

[laeubi]

As said, it's not trivial, please check bugzilla. I must have reported it for jdt or at least commented on it.

So what influences lamda ordering? Order of source files? classpath order? something else? I can't believe its completely random as at least we don't see these issues regularly so it seems to be quite constant for the same inputs.

[iloveeclipse]

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=578351

[laeubi]

Thanks I'll try to dig into this. Just as a quick update I can confirm that if I sort the source files by name I can exactly reproduce the warning we see in the Jenkins build, baseline compare complains that org/eclipse/pde/internal/launching/launcher/BundleLauncherHelper.class: different so order of input source files defiantly has an influence and the compiler backend uses the famous HashMap to collect source files that the are passed to the compiler arguments.

[laeubi]

I created

• https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1922

to mitigate the problem but some compiler expert might take a closer look.

[iloveeclipse]

With https://github.com/eclipse-jdt/eclipse.jdt.core/pull/1922 merged we will need to wait for the next SDK build to make ecj version updated in aggregator.

[laeubi]

With #1922 merged we will need to wait for the next SDK build to make ecj version updated in aggregator.

Should we start a new i build now?

[iloveeclipse]

Should we start a new i build now?

I'm busy with other work today, so if you want & plan to work on that, you can.

[laeubi]

Job is running: https://ci.eclipse.org/releng/job/Builds/job/I-build-4.31/117/ this will for sure require some bundle touches.

[iloveeclipse]

This one is needed now: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/1760

[laeubi]

I have now debugged with "old" Tycho not sorting the filenames and "new" Tycho that sorts the filenames but my fix in compiler still has not the desired effect....

I see that the CUs are using a sorted index array orderedIndex as expected but in the second case the outcome is still different as if I sort the raw file names instead, so there must be another place where the order of raw file names is used, will try to find out whats going on, but the arg parsing code is rather low level and hard to follow.

[laeubi]

One candidate is org.eclipse.jdt.internal.compiler.batch.FileSystem.initializeKnownFileNames(String[]) that uses a HashMap to build some lookup, but this is only used in org.eclipse.jdt.internal.compiler.batch.FileSystem.internalFindClass(String, char[], boolean, char[]) that do a contains check and looks innocent regarding ordering.