Panama source code fails to compile
Ty Young
youngty1997 at gmail.com
Mon Jan 4 16:58:50 UTC 2021
On 1/4/21 5:23 AM, Maurizio Cimadamore wrote:
> 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.
FWIW the changes were never merged into foreign-jextract(master) as far
as I can tell, only foreign-memaccess+abi.
The point I was making about the CLI is so people outside of Oracle know
what's working or isn't. This time around it was a bad merge that
introduced a duplicate function, which is the most trivial of trivial
fixes, but I've in the past seen wrong/non-existant constructors called
in Java code before too, in which case waiting and letting JDK
developers fix it is best I think.
>
> 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.
Those builds are generally too old and the changes from one to the next
can be massive. For the longest time it pointed to the old Pointer API
despite it being long abandoned. Things only happen to be better now
because Panama hasn't received major changes in months.
There are more IDEs out there than Intellij. I use Netbeans which, while
increasingly buggy as time goes on, does mostly work and was not
affected by the changes you mention. It handles JDK builds
built-fron-source surprisingly well actually, so long as you use those
builds as your boot JDK and Dr. Deprecator decided to take a vacation
for the JDK development cycle.
>
> 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.
I did a casual look over some of the code and there are a number of
mostly minor cleanups and API modifications that could be made IMO,
although only one so far that I've seen could probably be called major:
- AbstractLayout could be modified to use generics so that all layout
types no longer need to override standard MemoryLayout withers. The
Javadoc bug that prevented this from being done has long since been
fixed(JDK-8224052) in JDK 14. I've made the changes already here:
https://github.com/BlueGoliath/panama-foreign/commit/186ef819cd6e0da7d075c16926322a188f5846d8
Although I'm waiting on my OCA to be verified(does it need to be?)
before I do anymore pull requests other than:
https://github.com/openjdk/panama-foreign/pull/427
Which I can remove if someone needs me to.
- Padding layout should probably be a subclass of ValueLayout and just
override methods as needed. Having every memory layout have a
isPadding() method doesn't make much sense. The PaddingLayout class can
then be moved to an internal package as there is no way to create an
instance outside of ofPaddingBits as an API user. The same could be done
for AbstractLayout.
- GroupLayout should probably be split into StructLayout and
UnionLayout. This is the biggest change, but it simplifies the code,
provides better clarity on what's actually being represented, and allows
for future struct/union specific operations to be added without adding a
bunch of if(!isUnion) throw new UnsupportedOperationException(); type code.
This is just from me skimming the surface API code after submitting the
OCA, there are probably more changes although I doubt there is anything
major.
>
> 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