Panama source code fails to compile

[David Holmes]

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>
>>> À: "panama-dev at openjdk.java.net'" <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 
> 
> 
> 
> and
> 
> 
> 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 

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