[foreign] RFR 8209496: Minimize allocation in NativeInvoker::invokeNormal
John Rose
john.r.rose at oracle.com
Tue Aug 14 23:03:20 UTC 2018
Good change.
Those on-heap native structures are handy, aren't they?
We need to get those Pointers updated to value instances, to reduce temp. objects from offsetting.
The names of the form "foo_ptr" hurt my eyes. Surely they should be "fooPtr"?
Suggest "assert(n == 1)" at points where a 1-array used to be returned. In general,
it's hard to tell that the callers and callees are in agreement about the number of
argument slots being transferred.
*All* of the occurrences of "/ 8" make me uncomfortable, because I ask myself,
can the value ever be non-zero mod eight? I suggest a Util method something
like this to replace all uses of "/ 8":
long divExact(long x, long y) { if (x % y != 0) throw …; return x/y; }
Suggestion: Allow returnStructPtr to be null for struct returns that return via
registers, and just use the BoundedPointer.fromLongArray directly. Saves a copy
and a native allocation. Requires clarification that by-value struct returns are not
directly addressable by native code.
— John
On Aug 14, 2018, at 6:12 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> Hi,
> this patch avoids some expensive allocations in the NativeInvoker::invokeNormal code path. This code has to perform two tasks:
>
> * given an input array of (Java) object arguments, it has to copy the marshalled version of such arguments into a long array
>
> * given a long array contaning return value, it has to extract a Java object out of it (or copying the contents in the desired memory location)
>
> To carry out most of these operation, it suffices to operate at a low level, by viewing the long arrays managed by the system ABI as a 'heap' pointer (see new routine BoundedPointer::fromLongArray). From there, we can simply get/set values, using the pointer setter/getters which will directly affect the underlying array, with no need to go via a third pointer.
>
> Webrev:
>
> http://cr.openjdk.java.net/~mcimadamore/panama/8209496/
>
> P.S.
>
> Given the touched area is quite delicate, some testing on different platforms would be appreciated :-)
>
> Cheers
> Maurizio
>
More information about the panama-dev
mailing list