8000 Preserve size_t counts in managed-memory advice and prefetch by RicheyWorks · Pull Request #60 · jcuda/jcuda · GitHub
[go: up one dir, main page]

Skip to content

Preserve size_t counts in managed-memory advice and prefetch - #60

Draft
RicheyWorks wants to merge 1 commit into
jcuda:masterfrom
RicheyWorks:fix/managed-memory-count-width
Draft

RicheyWorks wants to merge 1 commit into
jcuda:masterfrom
RicheyWorks:fix/managed-memory-count-width

Conversation

@RicheyWorks
@RicheyWorks RicheyWorks commented Nov 4, 2026 •
Copy link
Copy Markdown

The driver/runtime managed-memory advice and prefetch wrappers cast Java's 64-bit count through C long. On Win64, long is 32 bits while CUDA takes size_t, so the wrappers silently lose the high bits. For example, advice for 4 GiB + 64 KiB is sent as just 64 KiB and can return success for a small allocation instead of rejecting the invalid range. Counts with bit 31 set may also sign-extend incorrectly.

Use size_t nativeCount = (size_t)count in all four affected wrappers (cuMemAdvise, cudaMemAdvise, cuMemPrefetchAsync, cudaMemPrefetchAsync), matching the CUDA signatures and nearby range-query wrappers. Four changed lines, no Java/JNI signature change. This is one count-width defect covering both APIs and operations.

Add six real driver/runtime advice cases: a valid 64 KiB range, 4 GiB + 64 KiB and 8 GiB + 64 KiB, each against an allocation of only 64 KiB. High-range cases require CUDA's invalid-value result, so a wrapped small success is observable without allocating gigabytes. Tests use private CPU-thread contexts, explicit status checks, managed-memory capability/64-bit checks and finally cleanup. No global exception-mode changes, prefetch calls, kernels, transfers or reset.

Verification on Windows x86_64, RTX 4090/driver 617.42, Temurin JDK 22/JUnit 4.13.1:

  • Published 12.6.0 JNI libraries: six tests, four failures; all oversized advice calls incorrectly return success, valid controls pass.
  • Rebuilt complete driver and runtime JNI libraries with only this patch and pristine jcuda-common 9d41fb5: all six pass under -Xcheck:jni, zero failures/errors/skips and no JNI warnings. JVM logging confirms both rebuilt DLL paths.
  • Both native builds use existing MSVC/CMake and checksum-verified workspace CUDA 12.6 headers/import libraries. Runtime links the verified 12.6 cudart import library; its DLL directory was added only to the test process PATH. Generated compiler/linker settings were checked for the explicit 12.6 include and import-library paths. No software installation or global environment change.
  • Java compilation uses proposed parent Target Java 8 in the parent compiler configuration jcuda-parent#2 installed normally. No overlapping count-truncation/MemAdvise issue or PR found.
  • Prefetch wrappers compile but were not executed. No valid multi-gigabyte allocation/advice, full CUDA suite, 32-bit ABI, Linux or other GPU model validated. This fixes argument forwarding; it does not promise device support for any operation or range.
  • Other workloads and Processing originals were not changed or paused.

CUDA contracts: driver unified addressing, runtime memory management.

mvn -f JCudaJava/pom.xml -Dtest=JCudaManagedMemoryCountTest "-DargLine=-Xcheck:jni -Djava.library.path=<rebuilt-native-directory>" test

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0