[foreign] RFR : Move array-like methods from Pointer to Array

[Jorn Vernee]

Oh, I see I forget to remove the unused imports from BoundedArray. Can 
you take care of that before pushing?

My IDE (Visual Studio Code) is having a lot of trouble with the JDK 
code, probably because of the dependency graph. I basically have no 
intellisense at all. Do you have any IDE tips? There seems to have been 
a netbeans project for the JDK in the past, but it no longer seems to be 
present. Most of the advice I've found on the internet is from <=jdk8.

Thanks,
Jorn

Maurizio Cimadamore schreef op 2018-11-20 13:30:
> I like it, really good
> 
> Thanks
> Maurizio
> 
> On 20/11/2018 12:20, Jorn Vernee wrote:
>> I realize I forgot about that yesterday.
>> 
>> I like your implementation, but LAST should be a pointer one past the 
>> end of the array to iterate over all elements. That's how it works in 
>> C/C++ as well, where you're allowed to have a pointer one past the 
>> last element of a container, as long as you don't dereference it. 
>> (I've also added a small test to check that the returned stream has 
>> the right size)
>> 
>> Naming it `iterate` as well makes sense to me, as it's essentially 
>> just another version of the Pointer::iterate method.
>> 
>> Updated webrev: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.05/
>> 
>> Maybe not in the scope of this RFR; should Array implement Iterable<X> 
>> and stream()? Currently we can get a stream of pointers-to-elements, I 
>> can imagine people being interested in getting a stream of just 
>> elements as well. Or should they just convert to a Java array for that 
>> (using toArray())?
>> 
>> Jorn
>> 
>> Maurizio Cimadamore schreef op 2018-11-20 02:42:
>>> Looks good - can the code in BoundedArray be rewritten in terms of
>>> Stream::iterate too? E.g. if you produce a pointer to the last 
>>> element
>>> - call it LAST - then it should be that
>>> 
>>> Array::elements()
>>> 
>>> ~=
>>> 
>>> Array.elementPointer().iterate(LAST)
>>> 
>>> Right?
>>> 
>>> Also, don't we want to rename this to iterate() too?
>>> 
>>> Maurizio
>>> 
>>> On 19/11/2018 18:20, Jorn Vernee wrote:
>>>> Update webrev: 
>>>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/arrays/webrev.04/
>>>> 
>>>> Added 2 `iterate` methods to Pointer, one that takes a predicate, 
>>>> and one that takes a pointer. Should I also add tests for these? 
>>>> (elements() was not being tested previously it seems).
>>>> 
>>>> Thanks,
>>>> Jorn
>>>> 
>>>> Maurizio Cimadamore schreef op 2018-11-19 16:27:
>>>>> <snip>
>>>>>>> 
>>>>>>> Stream<Pointer<T>> elements(Predicate<? super Predicate<T>> 
>>>>>>> hasNext)
>>>>>> 
>>>>>> Yes, this is a nice idea. Maybe we'd also want to have an overload 
>>>>>> that just takes a `Pointer<T>` as an argument, and iterations will 
>>>>>> be up until that pointer.
>>>>> Sure, the pointer-end overload sounds like a nice idea!
>>>>>> 
>>>>>>> And this would generally applicable to both arrays and pointers. 
>>>>>>> No
>>>>>>> guesswork involved, users iterating on pointers will have to 
>>>>>>> provide
>>>>>>> an explicit termination condition; if they get it wrong, they 
>>>>>>> will get
>>>>>>> some exception when dereferencing the wrong memory location.
>>>>>> 
>>>>>> Well, for native-allocated pointers this will invoke undefined 
>>>>>> behavior or possibly crash the VM (or enable access to VM 
>>>>>> internals? I'm not sure what security is in place there 
>>>>>> currently).
>>>>> 
>>>>> A possibility there would be to avoid using EVERYTHING as a backing
>>>>> region. That is, the binder could, in principle, generate regions 
>>>>> that
>>>>> are small enough only to contain the region that we actually want 
>>>>> to
>>>>> access (e.g. starts at base address , ends at base address + 
>>>>> pointee
>>>>> layout size). If the client is not happy with that and knows that 
>>>>> the
>>>>> pointer is a pointer to some kind of a buffer, perhaps an (unsafe?)
>>>>> operation could be provided to relax the memory region boundaries
>>>>> beneath the pointer.
>>>>> 
>>>>> But overall I think we should strive for the 'no VM crashes if you 
>>>>> are
>>>>> only using the safe API' (although we don't have to get there in 
>>>>> one
>>>>> step).
>>>>> 
>>>>> <snip>
>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> As a final point, I think we should implement elements() using
>>>>>>> Stream.iterate (and possibly document it in the API).
>>>>>> 
>>>>>> Agreed. Maybe we should also rename Pointer::elements to 
>>>>>> Pointer::iterate ?
>>>>> 
>>>>> I like that.
>>>>> 
>>>>> Cheers
>>>>> Maurizio
>>>>> 
>>>>>> 
>>>>>> Jorn