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

[Maurizio Cimadamore]

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