Re: Class Constants - pros and cons
Lew wrote:
Alan Gutierrez wrote:
The scenario under discussion is, I want to do something that will reach
the limits of system memory. Your solution is procure memory. My
solution is to use virtual memory.
Again, it seems to me that `MappedByteBuffer` and a bunch of little
facades to the contents of the `MappedByteBuffer` is a preferred
solution that respects memory usage. The design is as expandable,
easy-to-maintain and bug free as a great big array of objects, without
having to think much about memory management at all.
I like that idea.
Oh, yeah! Well another thing mister... You, I, uh, but... Wait...
Well, golly gee. Thanks.
I'd run off to write some code to illustrate my point.
package comp.lang.java.programmer;
import java.nio.ByteBuffer;
public interface ElementIO<T> {
public void write(ByteBuffer bytes, int index, T item);
public T read(ByteBuffer bytes, int index);
public int getRecordLength();
}
package comp.lang.java.programmer;
import java.nio.MappedByteBuffer;
import java.util.AbstractList;
public class BigList<T> extends AbstractList<T> {
private final ElementIO<T> io;
private final MappedByteBuffer bytes;
private int size;
public BigList(ElementIO<T> io, MappedByteBuffer bytes, int size) {
this.io = io;
this.bytes = bytes;
this.size = size;
}
// result is not `==` to value `set` so only use element type that
// defines `equals` (and `hashCode`).
@Override
public T get(int index) {
return io.read(bytes, index * io.getRecordLength());
}
@Override
public T set(int index, T item) {
if (index < 0 || index >= size) {
throw new IndexOutOfBoundsException();
}
T result = get(index);
io.write(bytes, index * io.getRecordLength(), item);
return result;
}
@Override
public void add(int index, T element) {
size++;
// probably off by one, but you get the idea...
for (int i = size - 2; i >= index; i--) {
set(index + 1, get(index));
}
set(index, element);
}
// and `remove` and the like, but of course only `get`, `set`
// and `add` to the very end can be counted on to be performant.
@Override
public int size() {
return size;
}
}
Create the above with however much `MappedByteBuffer` you need for your
Universe. Define `ElementIO` to read and write your `Star` type. Each
time you read a `Star` in `ElementIO` you do mint a new `Star` so that
is like Flyweight in some way, but seems like a little `Bridge` or
`Adaptor`.
If you shutdown soft and record the size, you can reopen the list. If
you change `Star` you need need to update `ElementIO` and rebuild your
list, but not probably not your code that references `Star` or the
`BigList`.
I don't know where "parallel" arrays come into play in the problem
Did you read this thread? Like, say, yesterday, when Tom McGlynn wrote:
E.g., suppose I were running a simulation of galaxy mergers
of two 100-million-star galaxies. Stars differ only in position,
velocity and mass. Rather than creating 200 million Star objects
I might create a combination flyweight/singleton Star where each
method call includes an index that is used to find the mutable
state in a few external arrays.
I see it now. Looking for the word parallel in the long thread didn't
find it for me, but that's what is described here. That does sound a bit
fragile.
Anyway, it seems like there is a middle ground between ORM+RMDBS and
everything in memory. My hobby horse. (Rock, rock, rock.)
--
Alan Gutierrez - alan@blogometer.com - http://twitter.com/bigeasy