Generic (void *)int
Giuseppe Barbieri
elect86 at gmail.com
Tue Feb 19 20:55:03 UTC 2019
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:
- 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)
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).
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