Generic (void *)int
Giuseppe Barbieri
elect86 at gmail.com
Wed Feb 20 00:25:15 UTC 2019
Let me add important text
checking clang-c/Index.h usability... yes
checking clang-c/Index.h presence... yes
checking for clang-c/Index.h... yes
checking for clang_getClangVersion in -lclang... no
configure: error: Cannot locate libclang or headers at the specified
locations:
/home/elect/Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/lib
/home/elect/Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/include
configure exiting with result code 1
It fails @clang_getClangVersion
Il giorno mer 20 feb 2019 alle ore 01:22 Giuseppe Barbieri <
elect86 at gmail.com> ha scritto:
> configure: error: Cannot locate libclang or headers at the specified
> locations:
>
> /home/elect/Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/lib
>
> /home/elect/Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/include
>
> Note, I had to choose 18.04 although I have 18.10 because it was the
> newest available
>
> Anyway, I'd not like to abuse your time, I can give up for the moment
> waiting until you or someone else will try and write down a guide for
> building on an updated ubuntu/linux system.
>
> Il giorno mer 20 feb 2019 alle ore 00:37 Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> ha scritto:
>
>>
>> On 19/02/2019 22:33, Giuseppe Barbieri wrote:
>>
>> I'll do as you said
>>
>> By "snapshot", do you mean the pre-built binaries?
>>
>> Yes
>>
>>
>> Just tried but apparently there seems to be no such option
>>
>> you need to update the branch
>>
>> $ hg update foreign
>>
>> Now the repo will be in sync with the Panama/foreign branch.
>>
>>
>> Maurizio
>>
>>
>> $ bash configure --disable-warnings-as-errors --with-libclang
>> ../../Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/
>> configure: WARNING: you should use --build, --host, --target
>> configure: WARNING: invalid host type:
>> ../../Documents/clang+llvm-7.0.1-x86_64-linux-gnu-ubuntu-18.04/
>> configure: error: unrecognized options: --with-libclang
>> configure exiting with result code 1
>>
>> then by:
>>
>> $ bash configure --help
>>
>> I went through all the `--with` and there is no such option
>>
>> The only llvm reference I found was
>>
>>
>>
>>
>> *The following toolchains are available as arguments to
>> --with-toolchain-type. Which are valid to use depends on the build
>> platform. gcc GNU Compiler Collection clang clang/LLVM*
>>
>> But I dont know if it's the same thing.. I guess not
>>
>>
>> Il giorno mar 19 feb 2019 alle ore 22:28 Maurizio Cimadamore <
>> maurizio.cimadamore at oracle.com> ha scritto:
>>
>>>
>>> On 19/02/2019 20:55, Giuseppe Barbieri wrote:
>>>
>>> That document is really enlightening, I think it should be added under
>>> "Links" here https://openjdk.java.net/projects/panama/
>>>
>>> I'll read it again and again in order to deeply grasp the concepts there
>>> expressed
>>>
>>> In the meanwhile, I'd love to being able to build it to try the very
>>> last changes, like `Scope.globalScope()`
>>>
>>> In this regards, the problem I get is the following
>>> https://gist.github.com/elect86/3365904008c5e7b0e9e58c9e31def671 if I
>>> do simply:
>>>
>>> There's a new build we issued just few hours ago which has this:
>>>
>>> https://jdk.java.net/panama/
>>>
>>> That said... comments below:
>>>
>>>
>>> - bash configure
>>> - make images
>>>
>>> It looks to be the same case of this user:
>>> https://mail.openjdk.java.net/pipermail/jdk-dev/2019-January/002520.html
>>>
>>> Ubuntu 18.10, gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1)
>>>
>>> Ok, so that seems an issue that has to do with the gcc compiler being to
>>> new - I'm on 7.3 on Ubuntu 18.04 and I don't have this issue - this is
>>> likely to be a JDK-wide issue as the email thread points out.
>>>
>>> If disabling warnings works for you, that's probably the best path until
>>> the underlying issue is fixed by the build team in mainline jdk/jdk.
>>>
>>> Also, it seems like I already have what seems necessary about llvm, or?
>>>
>>> $ sudo apt-get install clang-7 lldb-7 lld-7
>>> clang-7 is already the newest version
>>> (1:7.0.1~svn348686-1~exp1~20190113235558.10).
>>> lldb-7 is already the newest version
>>> (1:7.0.1~svn348686-1~exp1~20190113235558.10).
>>> lld-7 is already the newest version
>>> (1:7.0.1~svn348686-1~exp1~20190113235558.10).
>>>
>>> I'd advise *against* using the bundled clang that comes with Ubuntu -
>>> you can make that work, eventually, but it's a lot harder than just grab
>>> the latest LLVM snapshot at the link I provided and set a single build
>>> variable (instead of three). That's the way I build every day on Ubuntu
>>> (both 16.04 and 18.04).
>>>
>>> But you still have to pass LLVM to configure:
>>>
>>> $ sh configure --with-libclang <path to LLVM install> ...
>>>
>>> Otherwise the clang native library won't be built and your build will be
>>> missing jextract. A quick way to see if clang has been picked up by the
>>> build is to do this (from the JDK root):
>>>
>>> $ cat build/linux-x86_64-server-release/spec.gmk | grep CLANG
>>>
>>> If you see that the variables printed out do not contain any path
>>> pointing to your LLVM install, then it didn't work :-)
>>>
>>> Note to self: we should make the Panama/foreign configure step fail if
>>> LLVM is not found, rather than silently fail and then fail to produce
>>> jextract.
>>>
>>> Maurizio
>>>
>>>
>>>
>>> Giuseppe
>>>
>>>
>>> Il giorno mar 19 feb 2019 alle ore 12:09 Maurizio Cimadamore <
>>> maurizio.cimadamore at oracle.com> ha scritto:
>>>
>>>>
>>>> On 19/02/2019 07:17, Giuseppe Barbieri wrote:
>>>>
>>>> Ok, so first of all, thanks for your effort into this project
>>>>
>>>> Tthis is something extremely cool that I wished we had already from
>>>> some time
>>>>
>>>> JNI is quite tedious to work with (sorry), and on the other side JNA is
>>>> easier but can be quite slower for some applications.
>>>>
>>>> JNA is, however, nowhere so immediate and fast as using jextractor,
>>>> actually is extremely verbose..
>>>>
>>>> Coming back to feedback and observation, I think it's kind of critical
>>>> to understand exactly how shall `Scope` be used, which is the general
>>>> strategy to follow.
>>>>
>>>> Because I see a couple of options here (which are not ortogonal with
>>>> each other, a combination may be possible):
>>>>
>>>> - create a scope every method where you need allocation
>>>> - global scope for the whole project (and re-use all you can)
>>>> - class scope
>>>> - [3d real-time graphics or other performance critical app] (create it
>>>> once per frame and) pass it down the line
>>>>
>>>> Yep - all of this is possible, and it is ultimately up to the
>>>> application to do the right thing.
>>>>
>>>> Note that the Scope API is is being refined as we speak, according to
>>>> this proposal:
>>>>
>>>> https://cr.openjdk.java.net/~mcimadamore/panama/scopes.html
>>>>
>>>> Which introduces a stronger ownership model, and the concept of
>>>> 'library scope'. So you could also just use the library scope and allocate
>>>> everything there.
>>>>
>>>>
>>>> Also, what about multithreading? How Scope interact with that/which
>>>> properties has in this regard?
>>>>
>>>> This is covered in the document above - short answer: certain scopes
>>>> are more multi-thread friendly than others, and can have a fastest
>>>> implementation which just validates that the owning thread doesn't change
>>>> from creation time. But if you want to stash a scope into a field and keep
>>>> reusing it, you will run into races, so the implementation has to take care
>>>> of that (it doesn't now).
>>>>
>>>>
>>>> For example, I can say that GL, AL and CL require a fair amount of
>>>> native memory operations.
>>>>
>>>> VK, instead, is another planet: the amount of native structs and other
>>>> is massive, each method essentially create some info struct (kind of kotlin
>>>> data classes) just to hold a lot of parameters and then pass them as
>>>> argument to some function and retrieve an opaque object.
>>>>
>>>> How much is going to cost using Scope? Do you have any performance
>>>> metrics?
>>>>
>>>> We don't have concrete numbers for this specific axis yet - of course
>>>> if you end up allocating one scope per struct you are not much better off
>>>> than you would be allocating on heap, so some balance will have to be found
>>>> by the application. In terms of the VM, most of these scope instances can
>>>> be proven to be non-escaping, so their allocation shouldn't cost that much
>>>> (but escape analysis mileage is very conservative in Hotspot, and mileage
>>>> can vary - Graal might be better at that, with its partial escape analsysis
>>>> logic).
>>>>
>>>> Also, we are considering optimizations if the only thing a scope does
>>>> is allocating a _single_ resource.
>>>>
>>>>
>>>> Have you considered alternatives ways, such as thread-local/stack
>>>> allocations?
>>>>
>>>> One thing I noticed immediately is that there is no possibility to
>>>> deallocate pointer and other native resources, other than let the Scope be
>>>> GC"ed and with it all the corresponding native resources allocated with, I
>>>> guess.
>>>>
>>>> This is covered in the document - the short answer is that
>>>> de-allocating a single resource is a 'false friend' - if you go down that
>>>> path, you end up making pointers 'mutable' which will prevent them from
>>>> being true value types (which is our ultimate target - we want pointer
>>>> creation to be super cheap). Better to have immutable pointers-as-cursors,
>>>> and to put the mutable state elsewhere (scope).
>>>>
>>>>
>>>> So, this leads me think that the Scope class is supposed to be short
>>>> lived? But at the same time I'm afraid this may cause some pressure on the
>>>> GC under specific cases. I don't know.
>>>>
>>>> Nevertheless, I'd like to have some way to deallocate objects.
>>>>
>>>> Let's take as an example that hello triangle
>>>>
>>>> In the `init` (constructor) I do need to allocate for example several
>>>> resources, some of them can be trashed and freed right at the end of the
>>>> constructor, while some other instead shall survive since they are going to
>>>> be used in the render method, like the pMVP (to accomodate the matrix) and
>>>> the vertexArray (to hold the name).
>>>>
>>>> That seems to suggest that you need two scopes - one for the stuff that
>>>> is short-lived (scope can be created in the constructor) and another, more
>>>> global one, for the application. In the new model, described in the
>>>> document, you can start from the application scope:
>>>>
>>>> Scope appScope = Scope.globalScope().fork();
>>>>
>>>> And then, inside the constructor, you can 'fork' another scope:
>>>>
>>>> Scope constructorScope = appScope.fork();
>>>>
>>>>
>>>>
>>>>
>>>> A little note aside: I tried also to build it from source, I had to
>>>>
>>>> `bash configure --disable-warnings-as-errors`
>>>>
>>>> that's weird - this should not be needed... esp. on Linux - what
>>>> problem are you getting?
>>>>
>>>>
>>>> to avoid treating warnings like errors and it worked. But I don't see
>>>> any jextractor under ./build/linux-x86_64-server-release/images/jdk/bin/
>>>>
>>>> I wonder if this is related to the issue above - note that to build
>>>> jextract you need to point the build at clang - the easiest way to do that
>>>> is to download a snapshot here:
>>>>
>>>> http://releases.llvm.org/
>>>>
>>>> And then point the build at that:
>>>>
>>>> sh configure --with-libclang <path to LLVM install>
>>>>
>>>> This will generate the jextract library and, hopefully, will also get
>>>> rid of the warning.
>>>>
>>>> Maurizio
>>>>
>>>>
>>>>
>>>> Giuseppe
>>>>
>>>>
>>>> Il giorno lun 18 feb 2019 alle ore 15:33 Maurizio Cimadamore <
>>>> maurizio.cimadamore at oracle.com> ha scritto:
>>>>
>>>>> Whohoo!
>>>>> Looking forward to the feedback - and thanks for the patience!
>>>>>
>>>>> Maurizio
>>>>> On 18/02/2019 14:30, Giuseppe Barbieri wrote:
>>>>>
>>>>> Uh, sorry, my bad, you are right,
>>>>>
>>>>> ptr1.set(Vec3.lenght.L)
>>>>>
>>>>>
>>>>> should have been
>>>>>
>>>>> ptr1.set(Vec3.size.L)
>>>>>
>>>>>
>>>>> it works flawless! Thanks you all, guys
>>>>>
>>>>>
>>>>> I'll write later a list with some feedbacks to smooth the experience for gl devs
>>>>>
>>>>>
>>>>>
>>>>> Il giorno lun 18 feb 2019 alle ore 15:27 Maurizio Cimadamore <
>>>>> maurizio.cimadamore at oracle.com> ha scritto:
>>>>>
>>>>>> Uhm - the code snippet for converting long into pointer is correct; I
>>>>>> checked this on my machine:
>>>>>>
>>>>>> class Test {
>>>>>> public static void main(String[] args) throws Throwable {
>>>>>> try (Scope sc = Scope.globalScope().fork()) {
>>>>>> var ptr1 = sc.allocate(NativeTypes.LONG);
>>>>>> ptr1.set(42L);
>>>>>> var p1 =
>>>>>> ptr1.cast(NativeTypes.VOID).cast(NativeTypes.VOID.pointer()).get();
>>>>>> System.err.println(p1.addr());
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> And this prints 42 as expected.
>>>>>>
>>>>>> Are you sure the problem is coming from that pointer, and not from
>>>>>> somewhere else?
>>>>>>
>>>>>> Maurizio
>>>>>>
>>>>>> On 18/02/2019 14:16, Giuseppe Barbieri wrote:
>>>>>> > I just had a chance to try, but that, unfortunately, doesnt seem to
>>>>>> work..
>>>>>> >
>>>>>> https://github.com/elect86/panama/blob/master/src/test/kotlin/hello-triangle.kt#L100-L102
>>>>>> >
>>>>>> > I get a black triangle (I shall get a colored one instead)
>>>>>> >
>>>>>> > I guess I get at least the vertex positions (the triangle, although
>>>>>> black,
>>>>>> > is there) because in my case `semantic.attr.POSITION` is luckily
>>>>>> zero,
>>>>>> > which is the same index where the attributes start from.
>>>>>> >
>>>>>> > Other ideas?
>>>>>> >
>>>>>> > Il giorno lun 18 feb 2019 alle ore 10:56 Jorn Vernee <
>>>>>> jbvernee at xs4all.nl>
>>>>>> > ha scritto:
>>>>>> >
>>>>>> >> Hi Giuseppe,
>>>>>> >>
>>>>>> >> You should be able to use this trick:
>>>>>> >>
>>>>>> >> long pointerValue = 12L; // e.g.
>>>>>> >> Scope scope = Scope.newNativeScope; // or
>>>>>> Scope.globalScope().fork()
>>>>>> >> depending on which version you are
>>>>>> >> Pointer<Long> ptr = scope.allocate(NativeTypes.UINT64);
>>>>>> >> ptr.set(pointerValue);
>>>>>> >> Pointer<?> result =
>>>>>> >> ptr.cast(NativeTypes.VOID).cast(NativeTypes.VOID.pointer()).get();
>>>>>> >> // use 'result'
>>>>>> >>
>>>>>> >> Be aware that this does do an allocation of a 64 bit int, so you
>>>>>> might
>>>>>> >> want to reuse the allocated space if you create a lot of pointers
>>>>>> from
>>>>>> >> literals.
>>>>>> >>
>>>>>> >> Maybe in the future we can add an API for creating pointers from
>>>>>> long
>>>>>> >> literals directly.
>>>>>> >>
>>>>>> >> Jorn
>>>>>> >>
>>>>>> >> Giuseppe Barbieri schreef op 2019-02-18 10:44:
>>>>>> >>> Thanks Sundar,
>>>>>> >>>
>>>>>> >>> that works flawless for `(void *)0`
>>>>>> >>>
>>>>>> >>> But now I also would need a generic solution, for example:
>>>>>> >>>
>>>>>> >>> (void *)12
>>>>>> >>>
>>>>>> >>> There is a sill opengl call ( glVertexPointer ) requesting
>>>>>> explicitely
>>>>>> >>> that: https://stackoverflow.com/a/8283855/1047713
>>>>>> >>>
>>>>>> >>> Signature:
>>>>>> >>>
>>>>>> >>> void glVertexAttribPointer(int index, int size, int type, byte
>>>>>> >>> normalized, int stride, Pointer<?> pointer);
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> is there actually a way?
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> You can use Pointer.nullPointer() method.
>>>>>> >>>
>>>>>> >>> -Sundar
>>>>>> >>>
>>>>>> >>> On 18/02/19, 8:09 AM, Giuseppe Barbieri wrote:
>>>>>> >>>> Hi,
>>>>>> >>>>
>>>>>> >>>> I'm looking for a way to convert this:
>>>>>> >>>>
>>>>>> >>>> (void*)0
>>>>>> >>>>
>>>>>> >>>> in Java.
>>>>>> >>>>
>>>>>> >>>> I tried to allocate a pointer and set its value to 0, but it
>>>>>> didnt
>>>>>> >>>> work
>>>>>> >>>>
>>>>>> >>>> Any ideas, guys?
>>>>>> >>>>
>>>>>> >>>> Thanks in advance
>>>>>>
>>>>>
More information about the panama-dev
mailing list