Repository navigation
Read virtual-memory access locations from the nested object - #63
Draft
RicheyWorks wants to merge 1 commit into
Draft
RicheyWorks wants to merge 1 commit into
RicheyWorks wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
getCUmemAccessDescsobtains each descriptor's nestedlocation, but reads theCUmemLocationfield IDs from the outerCUmemAccessDesc.cuMemSetAccessconsequently uses a wrong object/field pairing and aborts under JNI checking before CUDA can validate the request.Read the location id/type from the already obtained
javaLocation. Two changed lines, no signatures or flag conversions changed. This is separate from #58's allocation-property/handle marshalling and #48's access-policy-window conversion; neither is included in this branch.Add three isolated child-JVM regression cases for no-access/read/read-write descriptors. The default mode submits a deliberately unmapped address with a nonzero size: safe JNI conversion must allow CUDA to return
CUDA_ERROR_INVALID_VALUE. It requires no allocation, mapping or pending allocation fix. Children enable JNI checking, capture diagnostics and have a 30-second timeout; contexts are destroyed on completion, and unsupported VMM devices skip explicitly.Verification on Windows x86_64, RTX 4090/driver 617.42, Temurin JDK 22/JUnit 4.13.1:
Field type (instance) mismatch in JNI get/set field operations.jcuda-common9d41fb5: all three pass, zero failures/errors/skips. A logged direct run confirms the rebuilt DLL and successful native error return, without JNI warnings.cuMemGetAccessround-trips and cleanup. This combined result depends on Fix virtual-memory allocation handle and property marshalling #58; the independent regression above does not.5ecd90cremains current. No kernels, data access/transfers, reset or ingestion pause.Independent mode after rebuilding this branch:
Optional actual-mapping validation, after applying #58 and rebuilding the combined driver:
Children enable JNI checking automatically. Mapped mode caps allocations at 16 MiB and frees mapping, virtual reservation, physical handle and context. On the test host only 2 MiB was used per case. CUDA contract: virtual memory management.