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

[Maurizio Cimadamore]

Pushed, thanks.

I took care of the imports and also of some javadoc issues.

Cheers
Maurizio


On 20/11/2018 12:41, Jorn Vernee wrote:
> 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