Once again! fast MappedObjects implementation

[Spasi]

CLMem mem = clCreateBuffer(clContext, CL_MEM_READ_ONLY | CL_MEM_ALLOC_HOST_PTR, nodes * Matrix4f.SIZEOF, errorCode);
ByteBuffer data = MappedObjectUnsafe.newBuffer(mem.getInfoLong(CL_MEM_HOST_PTR), (int)mem.getInfoSize(CL_MEM_SIZE));
Matrix4f matrices = Matrix4f.map(data);
Matrix4f.setIdentity(matrices, nodes);

Mapped access to CPU addressable PCIe memory? Check.

More requests:

• A getter for the mapped buffer in MappedObject will be useful. It’s one less reference to keep around when user code needs to pass the buffer to GL/CL.

• A .map(address, capacity) could be added, that would do the equivalent of lines 2-3 in the code above. MappedObjectUnsafe could be made package-private as well.

[Riven]

Interesting to see how you put my lib to use

What you’re doing, is rather dangerous at the moment. Once the GC deems the manipulated ByteBuffer collectable, it will free the address it’s pointing to, which is probably an illegal action, because that memory is not supposed to made available again through malloc(…) and last but not least might also be freed by the driver.

At least, that’s what little I (think I) know of what happens within ByteBuffer and how memory gets reused.

[Riven]

I think the best solution would be to never release the buffers, by storing them in some hidden collection, forever, maybe adding a method to release them.

[Spasi]

Nope, it’s safe because of .duplicate(). It uses a different constructor that doesn’t set a Deallocator, so Unsafe’s freeMemory won’t be called when the object gets garbage collected. It’s the same with JNI’s NewDirectByteBuffer.

[Spasi]

[quote=“Riven,post:62,topic:31992”]
Tbh, I would have created something like this on my own eventually. I’m currently doing research for an upcoming project that kinda requires fast buffer access. It was very fortunate that you started working on this now, saves me time and I’d never have thought about field access with bytecode transformation, so it’s a double win for me. That’s why I’m trying to contribute as much as I can, I need this to be as robust and complete as possible. I’m also pretty sure it’s not only me and Princec that are really happy about this library being available.

[Riven]

@Spasi

• A getter for the mapped buffer in MappedObject will be useful. It’s one less reference to keep around when user code needs to pass the buffer to GL/CL.

Keep in mind that the buffer is not necessarily linked to the baseAddress field, which might be very confusing.

@Spasi

Nope, it’s safe because of .duplicate(). It uses a different constructor that doesn’t set a Deallocator, so Unsafe’s freeMemory won’t be called when the object gets garbage collected. It’s the same with JNI’s NewDirectByteBuffer.

Okay, but it would still need a reference to its ‘parent’ buffer, to prevent its memory region from being freed.

I should probably look into the sourcecode to see what’s happening there.

[quote=“Spasi,post:65,topic:31992”]

@Riven

Tbh, I would have created something like this on my own eventually. I’m currently doing research for an upcoming project that kinda requires fast buffer access. It was very fortunate that you started working on this now, saves me time and I’d never have thought about field access with bytecode transformation, so it’s a double win for me. That’s why I’m trying to contribute as much as I can, I need this to be as robust and complete as possible. I’m also pretty sure it’s not only me and Princec that are really happy about this library being available.

Your ‘contributions’ are basically the only reason I keep updating the lib. It seems like nobody else cares, and I don’t really plan on using this lib myself

[Spasi]

[quote=“Riven,post:66,topic:31992”]
I guess you mean when there’s an offset involved? I can live with that.

[quote=“Riven,post:66,topic:31992”]
Indeed, there’s a “viewedBuffer” reference.

[princec]

@Riven

Your ‘contributions’ are basically the only reason I keep updating the lib. It seems like nobody else cares, and I don’t really plan on using this lib myself

I’m watching it carefully for the dust to settle so I can go and have a poke around it! My sprite engine is annoyingly much slower than it should be thanks to the relative slowness of filling data up in the buffers, so I’m interested to see how much faster (and nicer looking!) it can be made to be with this.

Cas

[concerto49]

I’m following this closely too.

[kappa]

@concerto49

I’m following this closely too.

me three

[divxdede]

me too, but only for interrest on the technical part, not really for using it.

[Matzon]

well, you’d need to license it for your games then - CC-NC…

[Riven]

@Matzon

well, you’d need to license it for your games then - CC-NC…

That doesn’t mean that I’d charge everybody for a commercial license… poor indies make an excellent exception

[nsigma]

@Matzon

well, you’d need to license it for your games then - CC-NC…

Bit OT, but I hate that Non-Commercial clause. It’s so misunderstood and ill-defined both generally and legally - just look at all the research and discussions around it when being ported to different jurisdictions. If that’s what you want, why not GPL + commercial? Worked for MySQL (getting bought up and bolloxed up by Oracle is an optional extra! ;D )

[Riven]

I might change it soon, after some research. Let’s not derail this thread into a license discussion.

[Riven]

http://indiespot.net/files/published/mappedobject-0.6.jar (view source)
Main-class: eden.mapped.TestMappedObject
JARs asm-3.2.jar and asm-util-3.2.jar (asm.ow2.org) must be on the classpath.

I coded mapped ByteBuffers by turning the GETFIELD into bytecode that creates a new ByteBuffer, located at the proper memory region:

@MappedType(sizeof = 64)
public class MappedSomething extends MappedObject
{
   @MappedField(byteOffset = 0)
   public int        used;

   @MappedField(byteOffset = 4, byteLength = 64 - 4)
   public ByteBuffer data;

   @Override
   public String toString()
   {
      return "MappedSomething[" + used + "]";
   }
}

      MappedSomething some = MappedSomething.malloc(4);

      if (some.data == some.data)
         throw new IllegalStateException("should be two distinct ByteBuffers");

      ByteBuffer buf = some.data;  // creates new ByteBuffer instance, it will always point to view #0

      some.view++;

      buf = some.data;  // creates new ByteBuffer instance, it will always point to view #1

It’s quite convenient this way, but the creation of the ByteBuffer adds some overhead. :emo:

Also, for traversing N mapped objects, use:

for(int i=0; i<N; i++)
{
    mapped.view = i;

    // stuff
}

not:

for(int mapped.view=0; mapped.view<N; mapped.view++)
{
    // stuff
}

maybe I will add an Iterator/Iterable for the convenient for-each loop.

[Spasi]

Could you drop .duplicate() from .backingByteBuffer()? The library doesn’t depend on the ByteBuffer state so I don’t think there’s a reason for the extra allocation there.

[Riven]

Fair enough. I updated it under version 0.6, as it’s a rather minor update.

Further, I added support for enhanced-for:

      for (MappedSomething item: foreach(mapped, viewCount))
      {
         System.out.println("item.view=" + item.view);
      }

which is a static import of MappedObject.foreach

Note that mapped==item, if you want an independant view, use dup()
Regardless of the initial value of ‘view’, you will iterate: [0…viewCount>
After the foreach, the view of ‘mapped’ == ‘viewCount-1’ (the last valid view, basically to prevent a native crash, when accessed after the loop!)

If anybody knows how to get this working with an instance-method, let me know. :point:

I also added MO.slice() which is identical to MO.dup(), except it does:
dst.baseAddress=src.viewAddress
which means is has similar characteristics as ByteBuffer.slice()

Bugfix in 0.6:

• copy/paste bug in jput(..) and iput(..)

[Riven]

@Spasi: sent you a PM.

[ra4king]

So uh, I still don’t get what the point of this library is