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

Tue Nov 20 13:44:42 UTC 2018

Wow thanks!

I knew there must have been a script somewhere to do IDE setup, but I 
was trying to find it in the docs, and in `make help`, which doesn't 
mention it. Also nothing on the OpenJDK wiki.

I tried out the VSCode config, but I was seeing an error about not being 
able to read the .project file.

I switched to intelij. That took some work, since the output project was 
using all the cygwin file system paths, but I seem to have gotten it to 
work.

Tbh, I don't really care which IDE I end up with, as long as I can use 
the Eclipse keymap ;)

Thanks a bunch,
Jorn

Maurizio Cimadamore schreef op 2018-11-20 14:02:
> So, IntelliJ is a more supported option to hack on the JDK. But I had
> some success to get VSCode up and running. I've installed the
> "language support for Java" extension (do not install the full Java
> pack, as that will bring in maven dependencies an all that).
> 
> My local configuration looks like:
> 
> 
> "workbench.editor.enablePreviewFromQuickOpen": false,
>     "extensions.ignoreRecommendations": false,
>     "terminal.integrated.rendererType": "dom",
>     "java.errors.incompleteClasspath.severity": "ignore",
>     "java.configuration.updateBuildConfiguration": "disabled",
>     "java.import.gradle.enabled": false,
>     "java.import.maven.enabled": false,
>     "java.autobuild.enabled": false,
>     "java.home": <PATH TO BUILT JDK>
> 
> 
> Then I have a toplevel .project file that looks like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <projectDescription>
>     <name>jdk</name>
>     <comment></comment>
>     <projects>
>     </projects>
>     <buildSpec>
>     </buildSpec>
>     <natures>
> <nature>org.eclipse.jdt.core.javanature</nature>
>     </natures>
> </projectDescription>
> 
> 
> And a toplevel .classpath file that looks like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <classpath>
>   <classpathentry excluding="module-info.java" kind="src"
> path="src/java.base/share/classes"/>
>   <classpathentry excluding="module-info.java" kind="src"
> path="src/jdk.jextract/share/classes"/>
>   <classpathentry excluding="module-info.java" kind="src"
> path="src/java.logging/share/classes"/>
>   <classpathentry excluding="module-info.java" kind="src"
> path="src/jdk.internal.opt/share/classes"/>
>   <classpathentry excluding="module-info.java" kind="src"
> path="src/jdk.internal.clang/share/classes"/>
>   <classpathentry excluding="module-info.java" kind="src"
> path="build/linux-x86_64-server-release/support/gensrc/java.base"/>
> </classpath>
> 
> (you might need to tweak the last entry)
> 
> 
> This setup works for me.
> 
> 
> If you go down the IntelliJ path, there's plenty of support. From a
> cygwin terminal you should be able to run (from toplevel JDK folder):
> 
> sh bin/idea.sh <module names>
> 
> e.g.
> 
> sh bin/idea.sh java.base
> 
> And this will inject all idea configuration files (specific to your
> platform/OS!) in the toplevel folder, so that you can open it with
> IntelliJ.
> 
> 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