[OpenJDK 2D-Dev] RFR: JDK-8198844 Clean up GensrcX11Wrappers

Phil Race philip.race at oracle.com
Mon Mar 5 22:38:18 UTC 2018

 >I'm not sure what role the "verification" step we had before ever played.
 >For all the years we've been "verifying" this, we've detected no 

I think this is useful in the event that you make some changes and
regenerate the 64 bit sizes but not 32 bit.

For example this old bug similarly reported a breakage on Solaris ..

... back in the day when we only had that checked in and the ones used 
for Linux
were being generated on the fly. My reading of the history here is 
sizes.32 and sizes.64
were added to support cross-compilation, and the verification step meant 
that  all
architectures would get checked in some build or other.

We care less about 32 bit now .. and even the cross-compilation .. so  
we could go back to always generating the files, as was the case for 
Linux before

But if we say we still want to keep around the possibility of 32 bit 
support AND
cross-compilation, then the verification step still seems useful.

If we say we care only about 32 bit or do not care about cross 
compilation, then
why not get rid of the checked in file and calculate these every build ?

The clean up of removing the solaris specific seems like it could have been
done a long time ago .. I am not sure why was ever only this one case there.
I'd have to dig back a very long way.

I do agree we do not need to support 32 + 64 bit concurrently, that went
away when 64 bit solaris overlay on 32 bit was dropped.


On 03/02/2018 07:23 AM, Erik Joelsson wrote:
> Adding 2d-dev in the hopes of getting some input from component team. 
> Seems like they should be aware of us removing the support for 
> multiple data models.
> Looks like you left a debug message at line 40 in GensrcX11Wrappers.gmk.
> /Erik
> On 2018-03-02 03:00, Magnus Ihse Bursie wrote:
>> On 2018-03-02 00:02, Erik Joelsson wrote:
>>> Hello,
>>> In xlibtypes.txt comment, should it be sizes-64.txt?
>> Yes, good catch.
>>> Generating both 32 and 64 seems a bit outdated at this point. Surely 
>>> this is a remnant of bundling 64 and 32 bit together on Solaris in 
>>> the past? Perhaps someone in 2d can answer this? Would be nice to be 
>>> able to clean up that part as well if possible.
>> Yes, you are right. We should clean up that as well. I was just too 
>> conservative. I've now actually checked what happens when you 
>> generate both 32 and 64 bit versions, and the result is that instead 
>> of code like:
>>     public static int getSize() { return 96; }
>> we get code like this:
>>     public static int getSize() { return ((XlibWrapper.dataModel == 
>> 32)?(80):(96)); }
>> Since we do no longer support multiple data models for the same 
>> build, this is just unnecessary. In fact, that leads to an even 
>> better cleanup, since we will always need just a single input file.
>> I also wrapped the tool calls in ExecuteWithLog.
>> Updated webrev:
>> http://cr.openjdk.java.net/~ihse/JDK-8198844-clean-up-GensrcX11Wrappers/webrev.02 
>> /Magnus

More information about the 2d-dev mailing list