Leverage accelerated vector hardware instructions in Vector Search.
Lucene already has a mechanism that enables the use of non-final JDK APIs, currently used for the Previewing Pamana Foreign API. This change expands this mechanism to include the Incubating Pamana Vector API. When the jdk.incubator.vector module is present at run time the Panamaized version of the low-level primitives used by Vector Search is enabled. If not present, the default scalar version of these low-level primitives is used (as it was previously).
Currently, we're only targeting support for JDK 20. A subsequent PR should evaluate JDK 21.
---------
Co-authored-by: Uwe Schindler <uschindler@apache.org>
Co-authored-by: Robert Muir <rmuir@apache.org>
* Define inputs and outputs for task validateJarLicenses
* Lazily configure validateJarLicenses
* Move functionality from copyTestResources task into processTestResources task
* Lazily configure processTestResources
* Altered TestCustomAnalyzer.testStopWordsFromFile() to find resources in updated location
* Resolve "overlapping output" issue preventing processTestResources from being cached
* Provide system properties from CommandLineArgumentProviders
* Configure certain system properties as inputs to take advantage of UP-TO-DATE checking
* Applies the correct pathing strategies to take full advantage of caching even if builds are executed from different locations on disk
* Make validateSourcePatterns task cacheable by removing .gradle directory from its input
* pass jvm args to javac #11925
* Update net.ltgt.errorprone to the latest version so that jvm args are not overwritten, add -XX:+PrintFlagsFinal for debugging
* speed up the pure javac case too
It does not help to fork additional VMs (although error-prone will do
this since it messes with bootstrap classpath), so we avoid forking.
Instead it is best to tune org.gradle.jvmargs.
* use the flags consistently everywhere (tests and doc)
* handle the different possible alt toolchain cases
The difference is invoking 'java' versus invoking 'javac', so the args must be fed differently.
Co-authored-by: Dawid Weiss <dawid.weiss@carrotsearch.com>
* pass jvm args to javac #11925
* Update net.ltgt.errorprone to the latest version so that jvm args are not overwritten, add -XX:+PrintFlagsFinal for debugging
* speed up the pure javac case too
It does not help to fork additional VMs (although error-prone will do
this since it messes with bootstrap classpath), so we avoid forking.
Instead it is best to tune org.gradle.jvmargs.
* use the flags consistently everywhere (tests and doc)
Co-authored-by: Dawid Weiss <dweiss@apache.org>
* pass jvm args to javac #11925
* Update net.ltgt.errorprone to the latest version so that jvm args are not overwritten, add -XX:+PrintFlagsFinal for debugging
* speed up the pure javac case too
It does not help to fork additional VMs (although error-prone will do
this since it messes with bootstrap classpath), so we avoid forking.
Instead it is best to tune org.gradle.jvmargs.
* use the flags consistently everywhere (tests and doc)
Co-authored-by: Robert Muir <rmuir@apache.org>
This uses Gradle's auto-provisioning to compile Java 19 classes and build a multi-release JAR from them. Please make sure to regenerate gradle.properties (delete it) or change "org.gradle.java.installations.auto-download" to "true"
Adds some build parameters to tune how tests run. There is an example
shown by "gradle helpLocalSettings"
Default C2 off in tests as it is wasteful locally and causes slowdown of
tests runs. You can override this by setting tests.jvmargs for gradle,
or args for ant.
Some crazy lucene stress tests may need to be toned down after the
change, as they may have been doing too many iterations by default...
but this is not a new problem.
Chris Hegarty
Tyler Bertrand
Uwe Schindler
Robert Muir
Dawid Weiss
Mike Drob
Dawid Weiss