Initial cut for a cuVS Java API by chatman · Pull Request #450 · rapidsai/cuvs

chatman · 2024-11-08T14:05:47Z

A Java API for cuVS for easy integration into Apache Lucene or other Java based projects.

Try:

./build.sh libcuvs
./build.sh java

For generating docs, mvn javadoc:javadoc

Prerequisites:

JDK 22
Maven 3.9.6+

Todo:

Generate project panama classes using jextract on every build
Algorithms other than Cagra
Prefiltering in cagra

Co-authored-by: Vivek Narang <vivek@searchscale.com>

copy-pr-bot · 2024-11-08T14:05:51Z

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

chatman · 2024-11-08T14:07:30Z

FYI @cjnolet ^
An ExampleApp.java is added as a starting point for the review.

cjnolet · 2024-11-08T16:06:56Z

/ok to test

chatman · 2024-11-18T02:56:53Z

@naramgvivek10 Let's move CuVSResources to the cuvs package instead of common? That way we can abstract out the internals of Panama out of sight of the users.

* Update CI script to update version in pom.xml files * Add and update examples * Add GPU info API methods --------- Co-authored-by: Vivek Narang <vivek@searchscale.com>

cjnolet · 2025-01-24T23:41:58Z

/ok to test

bdice

I skimmed the packaging details at @cjnolet's request. There are some merge conflicts with #593. ~~I will push a couple small packaging-related changes to this PR to help it move along.~~ I do not have power to push to this fork, so I can't help here. Please merge in branch-25.02 and run pre-commit.

The biggest work item needed on the packaging side is to clarify what versioning should look like. I think a patch version (25.02.0) is important to add here, as we often publish patch releases. Currently the update-version.sh script uses a full tag like 25.02.00 but that doesn't correspond to what the version strings look like right now. Also, we should probably normalize it to 25.02.0 (drop the extra leading zero), as we do for several packaging systems (all Python wheels are normalized, as is cuDF's Java layer). I would look at how cuDF versions its Java layer for more inspiration, which I linked in a comment.

bdice · 2025-01-26T05:02:41Z

ci/release/update-version.sh

+# Update Java API version
+sed_runner "s/VERSION=\".*\"/VERSION=\"${NEXT_FULL_TAG}\"/g" java/build.sh
+for FILE in java/*/pom.xml; do
+  sed_runner "/<!--CUVS_JAVA#VERSION_UPDATE_MARKER_START-->.*<!--CUVS_JAVA#VERSION_UPDATE_MARKER_END-->/s//<!--CUVS_JAVA#VERSION_UPDATE_MARKER_START--><version>${NEXT_FULL_TAG}<\/version><!--CUVS_JAVA#VERSION_UPDATE_MARKER_END-->/g" "${FILE}"


This is currently inconsistent with our normal use of the script. We usually run ./ci/release/update-version.sh 25.02.00 which would assign a value of 25.02.00. However, the pom.xml files use 25.02 without the patch version. I would guess that we do want to have a patch version here, but perhaps we want to normalize it to 25.02.0. That's close to what we do in cuDF's Java code.

Please look at https://github.com/rapidsai/cudf/blob/133e0c869531af94474e0bbb66cb22c5f8ba80f2/ci/release/update-version.sh#L87-L91 and https://github.com/rapidsai/cudf/blob/133e0c869531af94474e0bbb66cb22c5f8ba80f2/java/pom.xml#L24 and see whether we should adopt the same patterns here.

Thanks Bradley, I've updated the version number format to include a patch number also. This should be better for Java artifacts.

Do you think we should normalize it to 25.02.0 instead of 25.02.00? That would align with what we do for Java code elsewhere in RAPIDS, including cuDF and KvikIO.

Hey @bdice I will update the versioning following your suggestion above and push this change soon.

bdice · 2025-01-26T05:03:41Z

java/README.md

+Building
+--------
+
+`./build.sh` will generate the libcuvs_java.so file in internal/ directory, and then build the final jar file for the cuVS Java API in cuvs-java/ directory.


Suggested change

`./build.sh` will generate the libcuvs_java.so file in internal/ directory, and then build the final jar file for the cuVS Java API in cuvs-java/ directory.

`./build.sh` will generate the `libcuvs_java.so` file in the `internal/` directory, and then build the final jar file for the cuVS Java API in the `cuvs-java/` directory.

java/build.sh

java/cuvs-java/pom.xml

java/examples/pom.xml

rapids_config.cmake

… making version include a patch number, ability for .so to be loaded off env var

chatman · 2025-01-27T12:30:08Z

I updated the branch by merging latest branch-25.02 changes. Needed to add a filter param to cagra search (#452).
However, now tests don't work and I see the following (followed by JVM crash):
free(): double free detected in tcache 2

FYI @narangvivek10, please take a look.

chatman · 2025-01-27T14:24:39Z

(FYI @ChrisHegarty, @narangvivek10), Last working commit in this branch is:

Author: Vivek Narang <123010842+narangvivek10@users.noreply.github.com>
Date:   Fri Jan 24 14:45:44 2025 -0500

    Add examples, update GPU info API methods, and update CI script
    
    * Update CI script to update version in pom.xml files
    * Add and update examples
    * Add GPU info API methods
    ---------
    Co-authored-by: Vivek Narang <vivek@searchscale.com>

cjnolet · 2025-01-28T00:14:17Z

/ok to test

cjnolet · 2025-01-28T00:38:46Z

/ok to test

bdice · 2025-01-28T00:49:31Z

build.sh

+# Build the cuvs Java bindings
+if (( ${NUMARGS} == 0 )) || hasArg java; then
+    # build libcuvs first as the Java API depends on it
+    ./$0 libcuvs


I'm not sure if it is good practice to call this script recursively to build the C++ code. It seems like it will lead to unexpected behavior. For example, how do you ensure that the CLI arguments such as --allgpuarch or --no-mg are being passed through?

I would recommend removing this line, and users must call ./build.sh libcuvs java if the C++ has not yet been built. Perhaps a warning can be issued if hasArg libcuvs is false. I believe this is how we handle the Python builds, which also depend on C++ libraries being built.

Suggested change

./$0 libcuvs

bdice · 2025-01-28T00:50:37Z

cpp/cmake/thirdparty/get_dlpack.cmake

Please revert any files with only copyright changes.

bdice · 2025-01-28T00:52:43Z

ci/release/update-version.sh

+# Update Java API version
+sed_runner "s/VERSION=\".*\"/VERSION=\"${NEXT_FULL_TAG}\"/g" java/build.sh
+for FILE in java/*/pom.xml; do
+  sed_runner "/<!--CUVS_JAVA#VERSION_UPDATE_MARKER_START-->.*<!--CUVS_JAVA#VERSION_UPDATE_MARKER_END-->/s//<!--CUVS_JAVA#VERSION_UPDATE_MARKER_START--><version>${NEXT_FULL_TAG}<\/version><!--CUVS_JAVA#VERSION_UPDATE_MARKER_END-->/g" "${FILE}"


Do you think we should normalize it to 25.02.0 instead of 25.02.00? That would align with what we do for Java code elsewhere in RAPIDS, including cuDF and KvikIO.

…nd bruteforce

…date readme

cjnolet · 2025-01-29T01:23:10Z

/ok to test

cjnolet · 2025-01-29T03:37:59Z

/ok to test

cjnolet · 2025-01-30T01:05:27Z

/ok to test

cjnolet · 2025-01-30T01:10:04Z

@bdice the devcontainer build seems to be complaining about rmm::rmm target not being available in CMakeLists but I'm not seeing this behavior in any other PRs atm. The thing is, I'm not sure what would have changed in this PR that would have caused this behavior (and nothing seems immediately obvious to me). Do you have any ideas here?

This is the log for the devcontainer: https://github.com/rapidsai/cuvs/actions/runs/13024175979/job/36330368363?pr=450.

cjnolet · 2025-01-30T14:45:48Z

/ok to test

msarahan

Minor comment. You may want to run shellcheck on your .sh scripts. Mostly pedantic, but sometimes it catches annoying bugs.

Initial cut for a cuVS Java API

c777924

Co-authored-by: Vivek Narang <vivek@searchscale.com>

chatman requested review from a team as code owners November 8, 2024 14:05

chatman requested a review from msarahan November 8, 2024 14:05

github-actions bot added the CMake label Nov 8, 2024

cjnolet added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels Nov 8, 2024

cjnolet assigned chatman Nov 8, 2024

cjnolet changed the base branch from branch-24.10 to branch-24.12 November 8, 2024 16:06

narangvivek10 added 2 commits November 9, 2024 07:11

API changes, serialize optional tmpFile param + other changes

f9c2df7

make topK configurable

1597158

narangvivek10 force-pushed the java-api branch from 2cfab29 to 1597158 Compare November 11, 2024 15:07

narangvivek10 and others added 10 commits November 14, 2024 05:39

multiple fixes

6f405e9

pom file update

8531be2

sample test

c9b8891

sample test update + other changes

9bb865a

sample test update + use logging

d40b3d0

variable name updates + other

1e03585

Javadoc draft 1

3222536

Fixes for Javadocs, reducing visibility of internals, other refactorings

c5536b6

Loading the .so file from the jar instead of a hardcoded path

2d79580

package renaming and formatting

84c6121

chatman changed the title ~~[WIP] Initial cut for a cuVS Java API~~ Initial cut for a cuVS Java API Nov 18, 2024

narangvivek10 added 3 commits November 18, 2024 00:14

moving CuVSResources + other updates

20562ee

code refactoring

ad11369

javadoc maven config update and bug fixes

6a851ef

narangvivek10 and others added 2 commits January 24, 2025 14:45

Add examples, update GPU info API methods, and update CI script

a197d52

* Update CI script to update version in pom.xml files * Add and update examples * Add GPU info API methods --------- Co-authored-by: Vivek Narang <vivek@searchscale.com>

Merge branch 'branch-25.02' into java-api

69ef479

cjnolet approved these changes Jan 25, 2025

View reviewed changes

bdice reviewed Jan 26, 2025

View reviewed changes

ChrisHegarty and others added 3 commits January 27, 2025 09:37

Ensure Arena is closed when resources is closed

7eb00d5

Merge remote-tracking branch 'rapidsai/branch-25.02' into java-api

fd5e1c1

Fixing compile error due to additional filter param for cagra search,…

a24b3df

… making version include a patch number, ability for .so to be loaded off env var

narangvivek10 and others added 2 commits January 27, 2025 12:13

Merge branch 'branch-25.02' into java-api

daedfcd

close arena only if not alive, update version in pom.xml and cleanup

cf6efdd

bdice reviewed Jan 28, 2025

View reviewed changes

narangvivek10 and others added 5 commits January 27, 2025 21:42

Refactor GPU info API, search results and simplify mapping for hnsw a…

704d8d6

…nd bruteforce

Update Java versioning in the CI script

37c5dba

Merge branch 'branch-25.02' into java-api

c0d146b

Build script update, revert files with only copyright changes, and up…

8e42da0

…date readme

cleanup

136f658

Merge branch 'branch-25.02' into java-api

94a02fb

Merge remote-tracking branch 'rapidsai/branch-25.02' into java-api

083f706

msarahan approved these changes Jan 30, 2025

View reviewed changes

rapids-bot bot merged commit 4ca47c9 into rapidsai:branch-25.02 Jan 30, 2025
61 checks passed

bdice approved these changes Jan 30, 2025

View reviewed changes

	`./build.sh` will generate the libcuvs_java.so file in internal/ directory, and then build the final jar file for the cuVS Java API in cuvs-java/ directory.
	`./build.sh` will generate the `libcuvs_java.so` file in the `internal/` directory, and then build the final jar file for the cuVS Java API in the `cuvs-java/` directory.

Conversation

chatman commented Nov 8, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

copy-pr-bot bot commented Nov 8, 2024

Uh oh!

chatman commented Nov 8, 2024

Uh oh!

cjnolet commented Nov 8, 2024

Uh oh!

chatman commented Nov 18, 2024

Uh oh!

cjnolet commented Jan 24, 2025

Uh oh!

bdice left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chatman commented Jan 27, 2025

Uh oh!

chatman commented Jan 27, 2025

Uh oh!

cjnolet commented Jan 28, 2025

Uh oh!

cjnolet commented Jan 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cjnolet commented Jan 29, 2025

Uh oh!

cjnolet commented Jan 29, 2025

Uh oh!

cjnolet commented Jan 30, 2025

Uh oh!

cjnolet commented Jan 30, 2025

Uh oh!

cjnolet commented Jan 30, 2025

Uh oh!

msarahan left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

chatman commented Nov 8, 2024 •

edited

Loading

bdice left a comment •

edited

Loading