JDK-4445653 : RFE: Please add "long term pinned memory" support to JNI
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2001-04-14
  • Updated: 2001-05-16
  • Resolved: 2001-05-16
Related Reports
Duplicate :  
Description

Name: rmT116609			Date: 04/13/2001


C:\WINNT\Profiles\m_roulo\Desktop>c:\jbuilder3\java\bin\java -version
java version "1.2.2"
Java HotSpot(TM) Client VM (1.3.0rc3, mixed mode, build Z)

I would like to see added to JNI something I'm calling "long term pinned memory".

Issue:
-----

     Right now, I have a driver for some custom hardware that moves data from         the hardware into my program using DMA.  I must pass the driver a pointer        to the memory in my program  space that I want it to DMA into.

     Unfortunately, with JNI and HotSpot, I need  to _copy_ the memory after the      DMA transaction. This is because the JVM reserves the right to  move memory      around, and so with JNI under  HotSpot, when I pin memory, I get a copy.         Then  when I 'unpin' the  memory, I copy from the raw  'C' array back into       the Java array. I CAN'T PASS TO THE DRIVER THE RAW ADDRESS OF THE                UNDERLYING  MEMORY USED BY THE JAVA ARRAY.

     This is unfortunate because it requires an extra copy operation.  This           slows things down.

     What I would like would be some way from within JNI to 'pin' a Java object       such that it is truly pinned. Pinned so that it doesn't move and I have a        raw reference to the underlying memory.

     Since for the duration of the pin, the object won't be collectable, there        isn't much need to move or compact it, so the best thing to do might be to       move it UPON BEING PINNED to a region of memory that doesn't get copied by       the JVM. I can handle a single copy at the time of the pinning operation as      long as things don't move around afterwards.

     It is perfectly acceptable for this choice to only be allowed for:
    *) Objects that only contain primitive types (no  
       references), including arrays of primitives, _or_
     *) Just arrays of primitive types.
(Review ID: 120411) 
======================================================================

Comments
EVALUATION fred.oliver@East 2001-05-16 This is one of the driving issues for the NewIO package (JSR-0051), which is documented in bug 4313883. Closing this as a duplicate. See ByteBuffer.allocateDirect() and new JNI calls for obtaining addresses.
11-06-2004