GetLastError() (with and without debugger)

[Manuel Bleichenbacher]

I'm happy to see that discussion about this issue continues. It's the only
issue in project Panama that's really holding my work (
https://github.com/manuelbl/JavaDoesUSB) back. For all other issues,
there's a workaround.

You are probably far more familiar with the internals of the Java VM than I
am. But I can confirm that it's not a debugger only issue. The last error
is overwritten more frequently while debugging, but it occurs without the
debugger as well.

I don't share the fear that more errno-like things will come along. The
problem can only occur for errno-like things that are used by both the Java
VM and by third-party software. It cannot occur for some random third-party
library. So unless the Java VM starts using a new library with this ancient
pattern, it's a non-issue.

The proposed design looks good to me and aligned with the design principles
I've seen so far. It would certainly work my USB library.

The only open issue I see is with jextract. Would it be possible to
instruct jextract to generate code this extra action, or would this only
work with manually written binding code?

On Sat, Sep 10, 2022 at 1:50 AM John Rose <john.r.rose at oracle.com> wrote:

> On 12 Aug 2022, at 7:50, Maurizio Cimadamore wrote:
>
> On 12/08/2022 15:43, Pedro Lamarão wrote:
>
> … This would be a blocker for all applications of Windows API functions
> via panama.
> Windows Sockets has a similar mechanism called WSAGetLastError.
>
> And JNI - I doubt there's anything Panama specific here (unless proven
> otherwise).
>
> So that it's clear - it's not that GetLastError fails in general. It fails
> when a debugger is attached. As I explained, this could be due to _which_
> debugger is attached, or some existing issue (predating Panama) in the way
> jdb/JPDA deal with some Windows system calls.
>
> Maurizio
>
> Besides debugger interactions, I would worry about the VM itself doing
> some housekeeping functions between the two Panama calls. For example, if
> the first call ends at a safepoint request, the thread can go into
> safepoint-mode, and that is rather open-ended in its effects. If those
> effect include something as simple as a storage allocation (malloc) then
> the last-error in that thread might be reset. It’s hard to exclude such
> things unless we design in a real transaction of some sort which excludes
> all artifacts like safepoints or debugger operations.
>
> That’s why I nodded along when you, Maurizio, suggested a combinator for
> bundling together two downcalls into a single region. I see Jorn’s
> objection; it is in some sense a good design but it is very expensive to
> maintain, as a general-purpose facility. Imagine writing the regression
> tests…
>
> But, something like that transaction is clearly needed, though, for the
> specific operation of getting the last error. (Somebody is eventually going
> to come along with a second errno-like thing as well, which is a scary
> thought…) So we need, at least, a bespoke transactional feature for
> downcalls that saves the errno somewhere, no matter what. I like Vladimir’s
> suggestion for poking it down an extra argument.
>
> Here’s a slightly-general design for such a thing that is slightly
> future-proof, for the sake of brainstorming:
>
>    - Panama supplies a limited number of “extra actions” that can be
>    attached to any downcall.
>    - The only action defined initially gets a machine word which encodes
>    some sort of error state visible after a downcall.
>    - Adding more actions, and user control over them, is left for the
>    future.
>    - An extra action can have a return value. If you attach it to a
>    downcall, you can capture that return value by adding a trailing (appendix)
>    parameter, for a copy-out. Or, perhaps, you can route it directly,
>    replacing the main return value of the downcall.
>
> This picks up on the suggestion that downcalls can be configured to
> capture this extra information. And it generalizes the “save-error” feature.
>
> Finally, it makes the “ignore-error” feature unnecessary; that is a good
> thing, since if you have to opt into ignoring errors, it means that
> somebody is by default saving them for you. That is likely to turn into an
> overhead on every call, regardless of whether the saved data is useful or
> not.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220910/9cd6e3c3/attachment-0001.htm>