MappedObject library

Shared Code
#41

Surely Maven is a nice tool that solves every problem imaginable, but that doesn’t mean I have to put even more hours into supporting it than I already did. Add a to your POM and stop whining. If that’s too much effort, maybe this lib is not for you.

(btw: ‘you’ in the general term, not anybody in particular)

#42

You did all you need to do dude, there is absolutely no need at all to have stuff in Maven Central. If people have a problem with having to copy/paste the repository declaration to each project, just slap it in your user specific settings.xml to have it available for all projects at once. Of course that is less portable, but I have this idea that for most people using this library the portability isn’t really an issue.

#43

When I look at stuff like Maven I think to myself: “Wow! I could spend hours setting up a new tool and learning the basics so I can save myself minutes before something new-better-faster, yada-yada-yada comes along to replace it. Pass.”

[OnTopicMode]

Distant food for thought: data segregation via allowing breaking into multiple buffers.

@MappedField(stream = 0, offset = 0) ...
@MappedField(stream = 1, offset = 0) ...

[/OnTopicMode]

#44

Hmmm interesting so you’d actually back a mapped object by several bytebuffers?

Cas :slight_smile:

#45

Possibilities: endless
Available time: limited
Users: zero

:emo:

#46

@Cas: Yeah. Data-flow optimizations is the thought. Manual segregation is a total nightmare, but if you could rework in a couple of keystrokes…win!

@Riven: What I figured.

#47

You can actually pretty much fake it, if you know/restrict the maximum data size:


@MappedField(offset=0) public float x;
@MappedField(offset=4) public float y;
@MappedField(offset=8) public float z;

@MappedField(offset=0+1024*1024) public float r;
@MappedField(offset=4+1024*1024) public float g;
@MappedField(offset=8+1024*1024) public float b;

Althought it would be hardcoded per type instead of per instance.

#48

Good point.

#49

I’m pretty sure I might use this… It is soooo awesome ! :smiley:
c’mon Riven, there will be lots of guys using this (I truly believe).

#50

hmm maybe he should wait and see how people use it as it is before working any more on it eh? In the meantime there are more useful things our erstwhile slave can do like implement some sort of PHP kitchen sink in the forum.

Cas :slight_smile:

#51

Well component based kids should be interested. But breaking up into some number of fixed sized chunks is really a reasonable solution.

#52

It’s actually not that difficult:

Currently (float) field-access is rewritten to:


// in:
public class Vec3
{
    public float x, y, z;
}

// out:
public class Vec3
{
    public long address;
}

// access of field:
  Unsafe.getFloat(this.address + field.offset)

When supporting ‘streams’, it would be:


// in:
public class Vec3
{
    public float x, y, z;
}

// out:
public class Vec3
{
    public long xAddress, yAddress, zAddress;
}

// access of field:
  Unsafe.getFloat(this.*Address)

Obviously this can’t work (fast) in a MappedObjectArray, because I would have to move N pointers when calling .index(i) on a mapped type with N fields.

It works just fine with MappedObject though, but memory overhead becomes considerable, as the instances containing the offsets would easily become bigger than the data it refers to.

#53

Any chance of ASM 4 support?