> (taking the liberty of moving this thread to the devel list...)
> On Dec 19, 2012, at 9:22 AM, Siegmar Gross wrote:
> >> I think the real shortcoming is that there is no Datatype.Resized
> >> function. That can be fixed.
> > Are you sure? That would at least solve one problem.
> I think so. We "own" the bindings now, so adding a method is
> hypothetically possible. I can have a look at adding that over
> the holidays, but I make no promises...
> >> I noticed that if I used  in my version of the Scatter program,
> >> I got random results. But if I used  and did my own offset
> >> indexing, it worked.
Today I found something about the memory layout of 2D matrices in
Java (I'm not sure if the information is valid). Java has one 1D array
with pointers to every 1D row. All elements of a row are stored in
contiguous memory. Different rows can be stored in "arbitrary" places
so that a 2D matrix is normally not stored in a contiguous memory area.
It may even happen that rows with ascending indices are not stored in
ascending memory locations. If that is true, then Datatype.Vector
has much more to do in Java to build a column vector of a 2D matrix
than in C. Furthermore it wouldn't make sense in my opinion that the
extent of a column type is comparable to the true extent in C, because
in theory you can have an arbitrary order of the rows in main memory.
In fact it would be better in that case if the extent of a new column
type is equal to the extent of the base type of the array. It would also
be necessary that a new column type is something like an array itself
pointing for example to the first element of each row (perhaps it is
even possible to use the Java pointer array of the 2D matrix). To make
things worse, Java allows non-rectangular matrices (but they could be
prohibited for MPI). Perhaps this is no news to you, but I wanted to
mention it in case you also didn't know (as I said I'm not sure if the
information about 2D Java matrices is true).
> > I think if you want a 2D-matrix you should use a Java matrix and not
> > a special one with your own offset indexing. In my opinion that is
> > something a C programmer can/would do (I'm a C programmer myself with
> > a little Java knowledge), but the benefit of Java is that the programmer
> > should not know about addresses, memory layouts and similar things.
> Understood, and I agree.
> But if Java doesn't give any guarantees about memory layout, then how is MPI
supposed to handle this?
> > Now
> > I sound like my colleagues who always claim that my Java programs look
> > more like C programs than Java programs :-(. I know nothing about the
> > memory layout of a Java matrix or if the layout is stable during the
> > lifetime of the object, but I think that the Java interface should deal
> > with all these things if that is possible.
> It's quite possible/likely that Java implementations do deal with this stuff
-- they *have* to, right?
> But they don't necessarily expose it to external libraries (like MPI), thereby
making it impossible to do low-level actions, like directly accessing memory.
(again, I could be wrong here -- I'm NOT a Java expert!)
> FWIW: Fortran 2008 had similar issues. The MPI Forum had to directly interact
with the Fortran language standards body to get them to change some of these
guarantees so that MPI could access some of Fortran's lower-layer information.
> > I suppose that Open MPI will
> > not succeed in the Java world if it requires "special" matrices and a
> > special offset indexing. Perhaps some members of this list have very
> > good Java knowledge or even know the exact layout of Java matrices so
> > that Datatype.Vector can build a Java column vector from a Java matrix
> > which even contains valid values.
> Any Java expert input would be welcomed here...
> >> Remember: there is no standard for MPI and Java. So there is no
> >> "must". :-)
> > I know and I'm grateful that you try nevertheless to offer a Java
> > interface. Hopefully you will not misunderstand my "must". It wasn't
> > complaining, but trying to express that a "normal" Java user would
> > expect that he can implement an MPI program without special knowledge
> > about data layouts.
> Fair enough. Don't worry; I greatly appreciate the time and input that you're
spending on this. :-)
> >> ...snip...
> >> Again, here's my disclaimer that I'm not a Java guy... :-) But does
> >> this mean you need to define an operator method on your class, and
> >> that would allow this casting to work? (not that I'm sure what this
> >> method would need to *do*, but this is a first step...)
> > Alternatively the buffer parameter type could be changed from "Object"
> > to "Object". Then everybody would know that an array is expected
> > (even for a single value). However, I don't know if that has a
> > consequence which breaks other things. Is a different parameter type
> > possible or out-of any question?
> I got an out-of-band answer from a Java-expert friend yesterday that suggested
a better way to do this -- he suggested using a ByteArrayOutputStream.
> I'll try to look at this over the holidays.
> Jeff Squyres
> For corporate legal information go to: