Nicer way of interacting with upcalls?

[Maurizio Cimadamore]

Hi Mark,

On 24/01/2022 14:53, Mark Hammons wrote:
> Hi Panama development team!
>
> Recently, I released v0.1.0 of my library Slinc(
> https://mhammons.gitlab.io/slinc/blog/2021/01/22/V0-1-0-Released.html), and
> so far using the foreign interface has been great. However, there's one
> incongruity that really bugged me. Upcalls do not behave like other types
> in foreign. For all the other types that can be passed to C, I've been able
> to separate allocation of native space and writing data to native space.
> The process to create an upcall does both at once though, which makes it
> weird compared to other types (for example, can't replace an upcall without
> copying (at least temporarily) the new upcall to an unrelated address. Is
> there any way this could be rectified?

Not sure I get what you mean. You are right that, even for upcalls, 
there is an allocation side and an initialization side. That is, the JVM 
needs to allocate a code segment that is large enough to store all the 
machine instructions needed to call the target MH.

Since this allocation is VM-dependent (the allocation of the code 
segment occurs inside VM-managed memory), it seemed ok not to expose 
ways to "hide" the allocation of the code segment.

That said, an upcall stub is, at its core, just a pointer (e.g. 64 bits 
which point to some memory inside the JVM).

So, I'm not sure what you mean when you talk about temporary copies, 
etc. In both 17 and 18, the result of upcallStub is (or is convertible 
to) a MemoryAddress and you can get the raw long value associated to it 
(e.g. the physical address at which the upcall is stored).

If you have a struct with a funtcion pointer field and you want to 
update that field, you just set a new pointer in that field (the new 
pointer could be another pointer created via CLinker::upcallStub, or 
some other native pointer).

Maybe an example would better show what the issue is?

Thanks
Maurizio

>
> To be clear, I'd like two things if it's possible to add them: 1. a method
> or memory layout that can take a function descriptor and let me know the
> byte size needed to store 2. a method in MemoryAccess for writing a method
> handle (or maybe have upcall take a memory address/segment that it write
> stuff to).
>
> If I had these two things, function pointers in my library would not be a
> special case anymore.
>
> Thanks in advance for the great addition to the java standard library,
> looking forward to the improvements in java 18!
>
> ~Mark Hammons