[External] : Re: debug logging

Tue Aug 29 10:42:39 UTC 2023

Hi,

There is no nightly build of "foreign-memaccess+abi". If you don't want to build JDK, I think you may want to wait for a future JDK 22 early access build 🙂

Thanks,
-Sundar
________________________________
From: Rel <enatai at proton.me>
Sent: 29 August 2023 12:08
To: Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com>
Cc: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>; jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: [External] : Re: debug logging

Hi Sundar,

Thanks for reply.
I suppose this means that I need to use "panama" branch for the MR?

If so, do we have any nightly builds of "foreign-memaccess+abi"? The reason why I ask is that, it may really help me to focus on contributing to jextract rather than building OpenJDK from scratch :) Some Dockerfile with all build setup could help as well (so I then can just build OpenJDK and avoid preparing environment for that)

Otherwise I possibly wait until next Java 22 early access build?

Thank you,

------- Original Message -------
On Monday, August 28th, 2023 at 4:22 AM, Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com> wrote:

Hi,

The "panama" branch of "jextract" repo is the bleeding edge code. You need to build "foreign-memaccess+abi" branch of https://github.com/openjdk/panama-foreign<https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$> and pass the built JDK for "jdk22_home" parameter for jextract Gradle build script.

Hope this helps,
-Sundar
[https://opengraph.githubassets.com/2ade114bd2e33dddd5b0abf2e0b7789cdf5e118da91091f53a82150011d94dcb/openjdk/panama-foreign]<https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$>
GitHub - openjdk/panama-foreign: https://openjdk.org/projects/panama<https://urldefense.com/v3/__https://github.com/openjdk/panama-foreign__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPIVkS187g$>
https://openjdk.org/projects/panama. Contribute to openjdk/panama-foreign development by creating an account on GitHub.
github.com

________________________________
From: jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Rel <enatai at proton.me>
Sent: 27 August 2023 06:53
To: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Cc: jextract-dev at openjdk.org <jextract-dev at openjdk.org>
Subject: Re: debug logging

Thanks for reply and sharing the setup.

I will keep tracing separately in my branch and will not include it as part of logging Merge Request.

About MR: which branch should I use?

I tried "panama" branch with latest changes but since we switched to Java 22 in commit "ca8942c Update jextract/panama branch to track JDK 22" the build start failing for me:

jextract/src/main/java/org/openjdk/jextract/clang/Index.java:74: error: cannot find symbol
            MemorySegment src = arena.allocateFrom(file);
                                     ^
  symbol:   method allocateFrom(String)
  location: variable arena of type Arena

Java is:

java -version
openjdk version "22-ea" 2024-03-19
OpenJDK Runtime Environment (build 22-ea+12-877)
OpenJDK 64-Bit Server VM (build 22-ea+12-877, mixed mode, sharing)

This is the latest from https://jdk.java.net/22/<https://urldefense.com/v3/__https://jdk.java.net/22/__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPLO0H-bhA$>

------- Original Message -------
On Wednesday, August 23rd, 2023 at 12:22 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> On 23/08/2023 02:45, Rel wrote:
>
> > > That said, I think it's important we identify the categories of events
> > > that we are interested in logging. Logging clang parameters might be a
> > > good idea. As for parsing, I'm not too much of a fan of logging every
> > > single parsing event - as that would lead to very very long outputs.
> >
> > What do you think of:
> >
> > INFO - default mode, for everything where we use System.out
> > SEVERE - default mode, for everything where we use System.err
> > FINE - debug mode (clang parameters and some other useful logs)
> > FINER - tracing mode (parsing events, and basically "what jextract wanted to do before it
> > crashed" :). I understand the importance of not giving it to the users, so it will be available only
> > to developers and would require to be manually enabled in logging.properties file first and then would require to build a new binary)
> >
> > Do you think JUL would be a right candidate for logging in jextract?
>
> The classification you propose, as well as using JUL as a starting point
> doesn't seem too unreasonable.
>
> > > If my hunch is correct, I'd say that using a logger to allow for better
> > > debuggability when extending jextract is not the best way to do things.
> > > We should probably instead invest in making exceptions/errors more
> > > meaningful
> >
> > Curious to hear what others think here. The reasons why I found "tracing mode" is important are:
> > 1. Please correct me if I am wrong: as I see, the spirit of panama branch is to use most recent Java available out there (in fact it may not be even GA yet, like right now Java 22?). Because of that, it is most likely not to be supported by IDEs (jextract requires Java 22, Eclipse last time I checked supported only Java 20)
> > - because of no IDE support, debugging in IDE seems not possible and so "tracing mode" can help here
>
>
> I can run jextract/panama fine using IntelliJ - I have not tried with
> Eclipse.
>
> But your comment confirms my suspicion that, rather than logging things
> that are "interesting", we're basically trying to debug by println
> statements :-)
>
> I obviously understand where you are coming from (you are just trying to
> get things done) - but I'm not sure whetever level of finer logging we
> add would ever be able to replace a debugger - I'd suggest to try and
> use an IDE which works for your use case :-)
>
> (separately, as we have a gradle build to build jextract, how important
> it is that Eclipse understands Java N ? Maybe you'll miss some
> highlighting for the new features, but the rest should work? Or will
> Eclipse categorically refuse to debug a class with a version number it
> doesn't understand?)
>
> > 2. It helps to find what is wrong when use jextract for big projects (very very long outputs can be addressed with grep)
> >
> > How you debug jextract issues in panama branch now? And what would be the setup in this case (possibly such information is a good candidate for "jextract developer guide" later) so I can follow it
>
>
> See above - I use IntelliJ and its Gradle integration. I'm able to build
> fine. I have also installed the jtreg plugin:
>
> https://github.com/openjdk/jtreg/tree/master/plugins/idea<https://urldefense.com/v3/__https://github.com/openjdk/jtreg/tree/master/plugins/idea__;!!ACWV5N9M2RV99hQ!Pkg08TiIardCrx68xmpyPFVsYr-IejWPXxQ_5GH8A2tXaqarcBUVSbvwyRefWAq26nG2VxWCSTYv_YRh27LsSPLDR_AqbQ$>
>
> Which allows me to run tests and debug them.
>
> Finally, I have defined some execution targets to run jextract against
> some header files I've defined locally, to allow me to debug what happens.
>
> I'm pretty happy with this setup, and I feel quite productive with it.
>
> Hope this helps
> Maurizio
>
> > ------- Original Message -------
> > On Monday, August 21st, 2023 at 2:09 PM, Maurizio Cimadamore maurizio.cimadamore at oracle.com wrote:
> >
> > > Hi,
> > > I think adding better debugging capabilities to jextract is definitively
> > > helpful. I agree that right now jextract tends to be on the quiet side.
> > >
> > > That said, I think it's important we identify the categories of events
> > > that we are interested in logging. Logging clang parameters might be a
> > > good idea. As for parsing, I'm not too much of a fan of logging every
> > > single parsing event - as that would lead to very very long outputs.
> > >
> > > It almost seems like what you are looking for is some way to let
> > > jextract print some more info about what it wanted to do before it
> > > crashed. And I'm sure that this use case is mostly driven by the fact
> > > that you are working to extend jextract as opposed to use it.
> > >
> > > If my hunch is correct, I'd say that using a logger to allow for better
> > > debuggability when extending jextract is not the best way to do things.
> > > We should probably instead invest in making exceptions/errors more
> > > meaningful (I often wished I had a way to print the specific piece of C
> > > header we were about to parse when some exception occurred).
> > >
> > > And logging should instead be used for user-facing events (e.g. which
> > > headers are being parsed, which symbols are being excluded, which
> > > classes are being written, etc.).
> > >
> > > An example of that is this:
> > >
> > > > - Sometime you receive "Failed to parse
> > > > /tmp/jextract$1721579888733730008.h:" message, when you try to see
> > > > contents of /tmp/jextract$1721579888733730008.h to understand why it
> > > > is failed the file is already deleted.
> > >
> > > This is something a user should never see. E.g. if the user sees it - it
> > > is a bug - and you don't want better logging you (as a jextract user)
> > > just want it to be fixed.
> > >
> > > Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20230829/b1a4bbb9/attachment-0001.htm>