Non-NIO dynamic shared memory mapping

[Todd]

Hello,

I have spent some time trying to locate information on creating a
dynamic, shared memory-map that does not map a file, but uses the
memory allocated by the JVM. Does anyone have any suggestions as to
what I might search for? Or even better, if you have information
about how to implement such a thing, that would be great.

Basically, I am trying to allow a JVMTI enabled agent to read/write
memory for a user process. I understand how to use the NIO to do
this, but FileLock can't guarantee that it will actually lock (system
dependent). This will present some access contention that is not
acceptable for my situation.

I have also seen that rtsjx has something call SharedMemoryMapper, but
can not find any detailed information about this item. BTW, I have no
particular need for real-time Java.

Thanks

 

[Arne Vajhøj]

I have spent some time trying to locate information on creating a
dynamic, shared memory-map that does not map a file, but uses the
memory allocated by the JVM. Does anyone have any suggestions as to
what I might search for? Or even better, if you have information
about how to implement such a thing, that would be great.

Basically, I am trying to allow a JVMTI enabled agent to read/write
memory for a user process. I understand how to use the NIO to do
this, but FileLock can't guarantee that it will actually lock (system
dependent). This will present some access contention that is not
acceptable for my situation.

I have also seen that rtsjx has something call SharedMemoryMapper, but
can not find any detailed information about this item. BTW, I have no
particular need for real-time Java.

Not in pure Java.

JNI and some C Code making some system specific calls.

Arne

 

[Tom Anderson]

I have spent some time trying to locate information on creating a
dynamic, shared memory-map that does not map a file, but uses the memory
allocated by the JVM. Does anyone have any suggestions as to what I
might search for? Or even better, if you have information about how to
implement such a thing, that would be great.

If you can't find a way to do this in java, it shouldn't be that hard with
JNI: you need a function on the donor side which takes a pointer to a
direct ByteBuffer, does a GetDirectBufferAddress/GetDirectBufferCapacity,
then a shmget, and returns the shared memory ID, and one on the acceptor
side which takes a shared memory ID (and the length of the buffer), does a
shmat, then a NewDirectByteBuffer, and returns a pointer to the buffer.
These are the kind of short, straight-line functions that are fairly
painless with JNI.

Assuming you're on unix.

Basically, I am trying to allow a JVMTI enabled agent to read/write
memory for a user process. I understand how to use the NIO to do this,
but FileLock can't guarantee that it will actually lock (system
dependent). This will present some access contention that is not
acceptable for my situation.

Hang on, do you mean that FileLock doesn't guarantee a mandatory rather
than advisory lock, or something else?

tom

--
Formal logical proofs, and therefore programs - formal logical proofs
that particular computations are possible, expressed in a formal system
called a programming language - are utterly meaningless. To write a
computer program you have to come to terms with this, to accept that
whatever you might want the program to mean, the machine will blindly
follow its meaningless rules and come to some meaningless conclusion. --
Dehnadi and Bornat

 

[Todd]

Hang on, do you mean that FileLock doesn't guarantee a mandatory rather
than advisory lock, or something else?

Tom, from what I have read, FileLock is advisory, not mandatory, and
even that is dependent upon the operating system. This means that one
can't rely on the locking to satisfy synchronization issues.

Todd

 

[Arne Vajhøj]

Tom, from what I have read, FileLock is advisory, not mandatory, and
even that is dependent upon the operating system. This means that one
can't rely on the locking to satisfy synchronization issues.

The Java docs are very clear:

<quote>
This file-locking API is intended to map directly to the native locking
facility of the underlying operating system. Thus the locks held on a
file should be visible to all programs that have access to the file,
regardless of the language in which those programs are written.

Whether or not a lock actually prevents another program from accessing
the content of the locked region is system-dependent and therefore
unspecified. The native file-locking facilities of some systems are
merely advisory, meaning that programs must cooperatively observe a
known locking protocol in order to guarantee data integrity. On other
systems native file locks are mandatory, meaning that if one program
locks a region of a file then other programs are actually prevented from
accessing that region in a way that would violate the lock. On yet other
systems, whether native file locks are advisory or mandatory is
configurable on a per-file basis. To ensure consistent and correct
behavior across platforms, it is strongly recommended that the locks
provided by this API be used as if they were advisory locks.
</quote>

Arne

 

[Lew]

The Java docs are very clear:

<quote>
This file-locking API is intended to map directly to the native locking
facility of the underlying operating system. Thus the locks held on a
file should be visible to all programs that have access to the file,
regardless of the language in which those programs are written.

Whether or not a lock actually prevents another program from accessing
the content of the locked region is system-dependent and therefore
unspecified. The native file-locking facilities of some systems are
merely advisory, meaning that programs must cooperatively observe a
known locking protocol in order to guarantee data integrity. On other
systems native file locks are mandatory, meaning that if one program
locks a region of a file then other programs are actually prevented from
accessing that region in a way that would violate the lock. On yet other
systems, whether native file locks are advisory or mandatory is
configurable on a per-file basis. To ensure consistent and correct
behavior across platforms, it is strongly recommended that the locks
provided by this API be used as if they were advisory locks.
</quote>

Javadocs rule!

 

[Tom Anderson]

Tom, from what I have read, FileLock is advisory, not mandatory, and
even that is dependent upon the operating system.
Right.

This means that one can't rely on the locking to satisfy synchronization
issues.

Wrong! If all players in the game use locks properly, then it absolutely
will give you what you need.

The only difference between mandatory and advisory locks is in what
happens when dealing with a rule-breaker - a player who operates on things
without locking them properly. While this can be a problem in some
situations, i sincerely doubt it will be in yours, unless you think random
other processes are going to try editing your shared memory files.

tom