Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Walkaround suggestion to structs  (Read 2670 times)
0 Members and 1 Guest are viewing this topic.
Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Posted 2005-01-18 08:11:43 »

Princenc suggested:
"I just want fast memory mapped interfaces between ByteBuffers and Java Objects."

I wander if the brilliant engineers at Sun could implement this in their hotspot compiler? ->

While I don't really understand what Princec is talking about I do understand that there are people making small time classes for specific ops or whatnot which structs are generally used for under C and C#.

I have a better idea than to include structs.

Have the hotspot compiler measure the cost of the inside of the class (variable sizes and whatnot) and if the class size is below a certain threshold the hotspot compiler can perform a very aggressive operation on it to significantly reduce overhead of that class.

Why hasn't anyone suggested this before?

Can someone suggest this on JSR assuming they agree with the intention rather than my implementation.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2005-01-18 08:45:46 »

In a nutshell, no, it can't be done like that. There's only one solution to the problem, and there are only two arguments going on about it:

1. "I don't want no steeking structs in my beautiful language." A very lame counterargument from the same well-meaning people who should have devoted their efforts to getting the generics implementation fixed instead of bashing structs.

2. "I don't want it implemented like that, I want it like this..." etc. Quibbles over details.

Cas Smiley

Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #2 - Posted 2005-01-18 08:48:37 »

BTW, my solution wasn't refering to your problem.

I was using you as an example and didn't explain why I used you in my details.

My solution doesn't fix your problem of wanting to pass objects as memory streams.

I merely asking if my solution repairs the issue of small classes being agressively optimised so there is very little overhead in using them.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-01-18 09:26:14 »

There is no way to realistically shrink small classes any smaller than big classes. The overhead of an instance is constant. The only thing that can be done is local data can be allocated on the stack but we've been waiting an awfully long time for this much-requested feature.

Cas Smiley

Offline phazer

Junior Devvie




Come get some


« Reply #4 - Posted 2005-01-18 09:32:42 »

Of course Hotspot can optimize some classes as value types (or structs), but it's not as easy as you make it sound. What happens for example if there are multiple references to the same value object? Escape analysis and other methods can solve many of these problems and optimize objects as value types, but in the current JRE this is not fully exploited. For example, an immutable vector class is slower than a mutable with the current JRE. It shouldn't have to be.

Btw, I'm against adding a "struct"-type element to the Java language as it would introduce lots of problems for little value.

Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2005-01-18 10:42:24 »

All I want is syntactic sugar around a VM enhancement. The struct keyword could be used or it could simply detect classes extending javax.nio.Struct. It doesn't matter. All these wranglings fall into objection category #2. There is otherwise no valid reason to be against the purpose of "structs" or "memory mapped object instances".

Cas Smiley

Offline Raghar

Junior Devvie




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #6 - Posted 2005-01-18 17:08:44 »

class someClass implements unmutable (or fixedSize)
would be better. Do you remmember what happened to Vector? Some peole use it because simillar class is in C++.


Actually can you describe how would memory implementation differ in both cases?

You need a refference for both an object and a struct. You migth save some space by serialization of Object array into a single array. It could save some refferences, but could cause different problems.
Or were you interested in a bit copy of an object and throwing it somewhere else?

You seems to believe in a incredible speed of a stack. It's not the case in actual programming. Direct memory call is faster than push, or pop the stack.  Of course direct memory call could be 250 CPU cycles, so difference between talking to memory and stack out of L2 cache is very small.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2005-01-18 17:46:32 »

Er, who are you asking?

Cas Smiley

Offline Raghar

Junior Devvie




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #8 - Posted 2005-01-18 19:08:23 »

You can answer if you want.
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2005-01-18 21:00:23 »

The "struct" proposal is all about a) maintaining 100% java language compatibility without introducing *any* wierdness, b) completely removing the object overhead for large collections of mapped objects, and c) putting a nice object oriented front end on top of a flat buffer of memory.

A single instance of a struct has a bytebuffer on which it lives, and a position. A struct is a proper first class object like any other java object; it's passed by reference, it's garbage collected, etc. The only difference is that a struct's primitive fields are not allocated in the heap; instead they are mapped directly into the bytebuffer at the specified position in a consistent well-defined manner. Object fields are ignored for the purposes of the mapping.

What this means is you can have a huge big bytebuffer with a memory-friendly representation of, say, a BSP tree, just like in C or any other sane language. You create an instance of a Node struct, attach it to the bytebuffer, and position it somewhere. Bingo! The Node instance is effectively a pointer to a struct, except it's totally safe. You can do what the hell you like with your struct instance, it's just another Object.

So that's what structs do.

As for escape analysis - EA is just a really cheap optimisation for a compiler to do. It really is pretty simple to implement. It won't actually bring any speed increases in memory access or reduce object overhead particularly. What it will do is almost completely eliminate tons of little bits of garbage cluttering up the GC, leaving it to do its work on more important stuff. As a side effect it also means you can guarantee allocation time in many situations which is very important for a lot of people. Excelsior have used EA to very great effect in their JET JVM.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2005-01-19 10:56:57 »

Quote
The "struct" proposal is all about a) maintaining 100% java language compatibility without introducing *any* wierdness, b) completely removing the object overhead for large collections of mapped objects, and c) putting a nice object oriented front end on top of a flat buffer of memory.


Just out of interest...c.f. the thread on "java vs C++"...would structs *as you want them* help the issue of fast load times on weak CPU's, where in C++ you bake-in the pointers to the serialized file?

e.g. a low-power CPU (could be console, could be mobile) streams in a bytebuffer with all the level-data, and uses structs to start accessing the high-level object structure without actually having to go through the time of parsing game-file etc.

And, indeed, possibility of partial loading? Start using the structs *before* the full BB has finished streaming in? (although on low-power devices, usually you'd *have* to memmap or similar instead because you don't tend to have much RAM)

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2005-01-19 11:01:35 »

All pointers of course are meaningful only in the context of the buffer, i.e. there are no pointers, only "byte offsets" which you could move your struct to.

You could memmep a file into a mapped bytebuffer and use structs on it - nice. That's just one of the many great conveniences this API would bring.

Cas Smiley

Offline phazer

Junior Devvie




Come get some


« Reply #12 - Posted 2005-01-19 18:41:14 »

Can you explain more how the syntax for this would look? Do you just create a normal Java class and map it into a byte buffer, or something else?

I guess you could define a struct like this:
1  
2  
3  
4  
5  
class MyStruct {
  public int x;
  public int y;
  public char[] chars = new char[5]; // ?????
}

Object references are ignored you say. Are boolean's also ignored?

How do you map instances of this struct into a byte buffer? Something like this (?):
1  
MyStruct instance = MagicByteBufferAllocator.allocate(MyStruct.class, byteBuffer, index);

Huh

Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2005-01-19 20:26:54 »

Ideally:
1  
2  
3  
public struct Vector3f {
private float x, y, z;
}

but failing that
1  
2  
3  
4  
5  
6  
public class Vector3f extends javax.nio.Struct {
private float x, y, z;
Vector3f(ByteBuffer buffer) {
super(buffer);
}
}

Cas Smiley

Offline phazer

Junior Devvie




Come get some


« Reply #14 - Posted 2005-01-20 04:45:37 »

Ok, what about arrays?

1  
2  
3  
struct Data {
  char[5] chars; // ?
}


And you must be able to put a struct in a struct, right?

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
struct Data1 {
  int x;
  int y;
}

struct Data2 {
  Data1 d;
}

Data2 d2 = new Data2();


Would that mean that the value of 'd2.d' is also an object that is allocated when d2 is allocated?

Offline K.I.L.E.R

Senior Devvie




Java games rock!


« Reply #15 - Posted 2005-01-20 06:49:18 »

Will you guys scrap the 'struct' keyword.

All I'm asking for are compile time optimisations on small objects(classes) that can make them use less memory and have faster access than a normal class.

Vorax:
Is there a name for a "redneck" programmer?

Jeff:
Unemployed. Wink
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #16 - Posted 2005-01-20 09:36:20 »

Yeah, just forget the word "struct". They're objects like any other objects, and all they are is a little sliding view on top of a bytebuffer.

Object references are ignored in these mapped objects as there is no meaningful mapping of Object types to bytes - even for arrays. Think about it. So array types, sub-Structs, etc. - none of these will work, they'll be null (unless you go explicitly setting them to something). So just forget about using Structs or mapped objects in this way. They're for large quantities of complex primitive data, such as can be found in I/O and 3D.

Cas Smiley

Offline emmaps

Junior Newbie




Java games rock!


« Reply #17 - Posted 2005-01-21 10:45:01 »

So if I understand correctly, the difference between using objects for value collections and using a struct is how they are stored in the "stack" / extra calls?

Does using objects to store values give that more overhead than using structs, even on today's fast systems?  :-/
Offline princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #18 - Posted 2005-01-21 11:14:13 »

Vastly more overhead. Not only does it hugely tax the garbage collector but can almost double your memory requirements. Try storing a decent OOP version of a BSP in memory. Try loading one up quickly for that matter!

Cas Smiley

Offline Mark Thornton

Senior Devvie





« Reply #19 - Posted 2005-01-21 14:31:47 »

Quote
almost double your memory requirements.

Make your leaf nodes a bit bigger (i.e. put several polygons in each leaf node). I'm storing millions of curved lines (roads) with a 2-d index structure. The index is small relative to the actual data.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

toopeicgaming1999 (6 views)
2014-11-26 15:22:04

toopeicgaming1999 (7 views)
2014-11-26 15:20:36

toopeicgaming1999 (5 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (24 views)
2014-11-25 11:26:43

Gibbo3771 (22 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (74 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!