Panama source code fails to compile
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Mon Jan 4 11:23:31 UTC 2021
As usual, I find the tone of some of these emails way over the top.
We do have CI, both internally and externally. I don't think the GitHub
test was triggered during the merge, so the external CI did not run in
this case. Our internal CI ran as usual and did not report any error -
likely, as Remi said, because of a difference in the compiler being used.
I confirm that the problem can be reproduced on my system also - which
also sports a relatively recent GCC compiler (9.3.0).
> Just a little annoyed, sorry. I try to always use the latest builds so
> I don't have to constantly make large code changes, although there
> hasn't been many changes lately, which is odd. Is Panama's API nearly
> complete? What's the state of Panama at this point?
That's why we have binary snapshots :-)
We just released one before Christmas:
https://jdk.java.net/panama/
As discussed in a related thread, this is compatible with the API in 16,
so you can use jextract from there and then just use a 16 EA.
While this EA does not contain few jextract-related fixes, it is
recommended for most usages compared to the latest repo bits -
especially because the latest bits are unusable at least on IntelliJ
(changes to support strong encapsulation break the IDE which does not,
as of yet, officially supports Java 16). We will release another Panama
EA when the IDE situation has been cleared.
As for the state of the API, as the API is incubating we consider it to
be our best shot _so far_, but things might still change given targeted
feedback. Of course, the more we are iterating, the less substantial API
changes you are seeing.
Cheers
Maurizio
On 29/12/2020 21:12, Ty Young wrote:
> Yes, mostly. Things happen, especially on holidays when everyone has
> things to do and places to be. I was going to wait until after the new
> year to bring it up, but I had seen JDK developers replying to things
> so I figured they were back.
>
>
> A proper CI could have at least warned that there is an issue, just
> like other previous issues. Having newer JDK builds would be a benefit
> to projects like Panama as it reduces the hurdle to try out recent
> versions, especially those on Windows. Again, probably screaming into
> the void on the CI thing.
>
>
> On 12/29/20 5:21 AM, Samuel Audet wrote:
>> Hi,
>>
>> I think the point is that this could have been prevented with proper
>> CI. Since the repos are now on GitHub, OpenJDK could easily benefit
>> from GitHub Actions...
>>
>> Samuel
>>
>> On Tue, Dec 29, 2020, 16:39 David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>> On 29/12/2020 1:06 pm, Ty Young wrote:
>> >
>> > On 12/28/20 3:18 PM, Remi Forax wrote:
>> >> ----- Mail original -----
>> >>> De: "Ty Young" <youngty1997 at gmail.com
>> <mailto:youngty1997 at gmail.com>>
>> >>> À: "panama-dev at openjdk.java.net
>> <mailto:panama-dev at openjdk.java.net>'"
>> <panama-dev at openjdk.java.net <mailto:panama-dev at openjdk.java.net>>
>> >>> Envoyé: Lundi 28 Décembre 2020 22:06:58
>> >>> Objet: Panama source code fails to compile
>> >>> Just an FYI, the Panama source code have been broken since
>> before
>> >>> Christmas with this error:
>> >>>
>> >>>
>> >>> panama-foreign/src/hotspot/share/oops/methodData.cpp:1616:6:
>> error:
>> >>> redefinition of 'static bool
>> MethodData::profile_memory_access(const
>> >>> methodHandle&, int)'
>> >>> 1616 | bool MethodData::profile_memory_access(const
>> methodHandle& m,
>> >>> int bci) {
>> >>> | ^~~~~~~~~~
>> >>>
>> /run/media/ty/Windows_Linux_Shared/OpenJDK/panama-foreign/src/hotspot/share/oops/methodData.cpp:1604:6:
>>
>> >>>
>> >>> note: 'static bool MethodData::profile_memory_access(const
>> >>> methodHandle&, int)' previously defined here
>> >>> 1604 | bool MethodData::profile_memory_access(const
>> methodHandle& m,
>> >>> int bci) {
>> >>> |
>> >>>
>> >>>
>> >>> I tried building using the usual `bash configure
>> >>> --disable-warnings-as-errors` and `make images` on (Arch)
>> Linux. I am
>> >>> able to compile the standard JDK from source just fine.
>> >>>
>> >>>
>> >>> I know I'm probably (metaphorically) screaming into the void
>> here but...
>> >>> people often have data caps and JDK source code is *A LOT*.
>> Not to
>> >>> mention the CPU and memory requirements needed to compile it
>> in a
>> >>> reasonable amount of time, which are massive. I suggested
>> months ago on
>> >>> the skara-dev list on having build succeeded/failed badges
>> and/or
>> >>> automatic JDK builds but apparently no one is interested
>> because it
>> >>> hasn't been added. Is making sure your code compiles & runs
>> before you
>> >>> push it not a requirement for JDK developers or something? I
>> understand
>> >>> it was Christmas but this has happened a few times now.
>> >> Usually for this kind of error, it's because you are compiling
>> with a
>> >> c++ compiler more recent than the one used by the CI,
>> >> so the bug flies under the radar.
>> >
>> >
>> > There is clearly a duplicate declaration:
>> >
>> >
>> >
>> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1604
>> <https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1604>
>>
>> >
>> >
>> >
>> > and
>> >
>> >
>> >
>> https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616
>> <https://github.com/openjdk/panama-foreign/blob/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616>
>>
>> >
>> >
>> >
>> > are the same. Git blame shows that the duplicate was added 17
>> days ago:
>> >
>> >
>> >
>> https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616
>> <https://github.com/openjdk/panama-foreign/blame/5a8d47fd226708e46f56ec82294e9c786f6850c1/src/hotspot/share/oops/methodData.cpp#L1616>
>>
>>
>> I think I see what happened.
>>
>> JDK-8257692 was fixed in the panama-foreign repo in foreign-jextract
>> branch.
>>
>> JDK-8258242 was fixed in the mainline JDK and contained some of
>> the same
>> code changes.
>>
>> A few days before Christmas there was an auto-merge between
>> panama-foreign and mainline JDK, and that is when the duplicate code
>> chunk has arisen.
>>
>> David
>> -----
>>
>> >
>> >
>> > and removing the duplicate allows the JDK to build correctly.
>> >
>> >
>> > So, no, this has nothing to do with the distro or the compiler I
>> use.
>> > I've already been through this blame game nonsense on swing-dev
>> with JDK
>> > developers when they broke literally every Swing application
>> that used
>> > GTK L&F on Arch Linux, lets not do it again, please.
>> >
>> >
>> >>
>> >>>
>> >>> Just a little annoyed, sorry. I try to always use the latest
>> builds so I
>> >>> don't have to constantly make large code changes, although
>> there hasn't
>> >>> been many changes lately, which is odd. Is Panama's API nearly
>> complete?
>> >>> What's the state of Panama at this point?
>> >> Rémi
>>
More information about the panama-dev
mailing list