Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Hendrik Schreiber]

Jim,

if there isn’t a dedicated bug report for this (meaning: lack of optimization 
for macOS), please do create one so that it at least is documented somewhere.

Thank you,

-hendrik

> On Jun 5, 2020, at 13:59, Jim Laskey  wrote:
> 
> I know there was a discussion about this elsewhere but I would like to take 
> the opportunity to correct this now
> 
> make//autoconf/flags-cflags.m4:241
> 
>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
> if test "x$OPENJDK_TARGET_OS" = xmacosx; then
>   # On MacOSX we optimize for size, something
>   # we should do for all platforms?
>   C_O_FLAG_HIGHEST_JVM="-Os"
>   C_O_FLAG_HIGHEST="-Os"
>   C_O_FLAG_HI="-Os"
>   C_O_FLAG_NORM="-Os"
>   C_O_FLAG_DEBUG_JVM=""
> else
>   C_O_FLAG_HIGHEST_JVM="-O3"
>   C_O_FLAG_HIGHEST="-O3"
>   C_O_FLAG_HI="-O3"
>   C_O_FLAG_NORM="-O2"
>   C_O_FLAG_DEBUG_JVM="-O0"
> fi
> C_O_FLAG_SIZE="-Os"
> C_O_FLAG_DEBUG="-O0"
> C_O_FLAG_NONE="-O0"
>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
> 
> should be changed to 
> 
>   elif test "x$TOOLCHAIN_TYPE" = xclang; then
> C_O_FLAG_HIGHEST_JVM="-O3"
> C_O_FLAG_HIGHEST="-O3"
> C_O_FLAG_HI="-O3"
> C_O_FLAG_NORM="-O2"
> C_O_FLAG_DEBUG_JVM="-O0"
> C_O_FLAG_SIZE="-Os"
> C_O_FLAG_DEBUG="-O0"
> C_O_FLAG_NONE="-O0"
>   elif test "x$TOOLCHAIN_TYPE" = xxlc; then
> 
> MacOSX has been paying a historic and significant performance penalty for no 
> valid reason.
> 
> Otherwise +1.
> 
> Cheers,
> 
> -- Jim
> 
> 
> 
>> On Jun 5, 2020, at 4:52 AM, Kim Barrett > > wrote:
>> 
>> [Changes are only to the build system, but since the changes have jdk-wide
>> effect I’ve cc’d what I think are the relevant dev lists.]
>> 
>> This change is part of JEP 347; the intent is to target JDK 16.
>> 
>> Please review this change to the building of C++ code in the JDK to
>> enable the use of C++14 language features.  This change does not make
>> any code changes to use new features provided by C++11 or C++14.
>> 
>> This requires trimming the supported compiler versions, moving the
>> minimum supported versions forward (significantly, in some cases).
>> The new minimums are based on compiler documentation rather than
>> testing.  It may be that more recent versions are actually required.
>> 
>> This change needs to be tested on platforms not supported by Oracle.
>> The JEP test plan includes additional Oracle testing beyond what I’ve done.
>> 
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8246032 
>> 
>> 
>> Webrev:
>> https://cr.openjdk.java.net/~kbarrett/8246032/open.02/
>> 
>> Testing:
>> mach5 tier1-5 on Oracle supported platforms.
>> 
>> Performance testing showed no significant changes in either direction.
>> 
>> Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le
>> 
> 

Re: Windows: Replace VisualStudio with gcc/clang?

[Hendrik Schreiber]

>> 
>> From my perspective, something needs to change, as I found it
>> completely impossible to install the old Visual Studio releases the
>> JDK demands (and it took ages just to find them). Requiring outdated
>> tooling to build the JDK really isn't great.
>> 
>> Stephen
>> 
> 
> I agree. This is what I meant when I wrote earlier:
> 
> "Also, installing Visual Studio could be easier by making sure that we
> always can build with the latest community version, early when it comes
> out. Since it is not so easy to find community/express/whatever downloads
> for earlier versions of Visual Studio. "

I guess, if you have a clean system that you use for nothing else but playing 
with OpenJDK, it’s relatively easy.

But I have found that keeping multiple VS installations in parallel on a single 
machine is challenging to say the least. Whenever I want to do something for 
OpenJDK, I fear for other build environments that have different needs. The 
gcc/clang suggestion was born out of the assumption that they are much easier 
to manage/choose from the command line. I still remember the hoops one had to 
jump through to get a 64bit compiler installed under VS. This all may just be 
“perceived” difficulties due to unfamiliarity, but they’re still real.

The Visual Studio Build Tools may solve most of the issues I have with VS. And 
perhaps it’s less of a monster to download.

-hendrik

Re: problems with freetype.dll, jdk 8 and windows

[Hendrik Schreiber]

> On Mar 7, 2016, at 17:50, Phil Race <philip.r...@oracle.com> wrote:
> 
> On 03/07/2016 08:11 AM, Hendrik Schreiber wrote:
>> - System Setup: freetype is listed as a requirement for Linux and Solaris. 
>> But not for Windows.
> 
> I don't think that is completely accurate.

What I meant to point out is, that the README document has a section called 
“System Setup”. It seems to specify needed requisites for different platforms, 
namely Linux, Solaris, Windows and Mac OS X.

Under none of the “Windows” headings, freetype is listed. But clearly, to build 
the JDK for Windows, you need freetype installed or at least the sources 
accessible.

But that’s beside the point. I’m sure one can guess and assume one’s way 
through the whole thing just fine.

I really just wanted to list some things that would have made it easier *for 
me* to get going, assuming that it would also make it easier for other people. 
IMHO, a little verbosity does not hurt in such a document.

Please don’t take my email as an annoyance. I just wanted to point some things 
out that most people working with the JDK for years would probably never 
notice, simply because they have no need to read the README file in the first 
place.

Cheers!

-hendrik

Re: problems with freetype.dll, jdk 8 and windows

[Hendrik Schreiber]

>> 
>> BTW—Something that puzzles me but probably has a straight forward 
>> explanation: Why is there no freetype.dll in the pre-built JDKs (either 8 or 
>> 9)? Shouldn’t that be in there somewhere? I was thinking that would be a 
>> great source for a correctly built binary lib..
> 
> If by "pre-built" you mean the Oracle JDKs, they don't use/require freetype - 
> only OpenJDK does.

Ah! Thanks, David, for pointing this out. I was not aware of it.

-hendrik

problems with freetype.dll, jdk 8 and windows

[Hendrik Schreiber]

Hey there,

I’m trying to build a 32 bit JDK8u with Windows. And hoorray! it’s building 
just fine.
But when running some software I run into:

java.lang.UnsatisfiedLinkError: C:\…\jre\bin\freetype.dll: %1 is not a valid 
Win32 application

Apparently, I am not the first one with this problem. 
http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014091.html seems 
to have faced the same issue and was told:


“Freetype on Windows has long been a frustrating source of problems.

In JDK9 there is a new configure option, --with-freetype-src, which 
helps out a lot with the problematic freetype on Windows. It just 
requires you to download the freetype source code and it will 
automatically compile a correct freetype library for use by OpenJDK.

AFAIK this patch has not been backported to JDK8, however. But if you 
can switch to JDK9 I highly recommend  it. An alternative solution might 
be to download JDK9 just to use this feature, and then point to the 
newly built freetype library using configure in JDK8.”


I can definitely confirm that first statement…

Is there any other, easy recommended way how to deal with this on for 8u. I’d 
like to avoid having to deal at all with JDK9 at this point. Perhaps someone 
has a correctly built 32 bit dll lying around...?

BTW—Something that puzzles me but probably has a straight forward explanation: 
Why is there no freetype.dll in the pre-built JDKs (either 8 or 9)? Shouldn’t 
that be in there somewhere? I was thinking that would be a great source for a 
correctly built binary lib..

Thanks!

-hendrik

Re: get_source.sh does not seem to work, fails on jdk/src/closed

[Hendrik Schreiber]

> On Mar 6, 2016, at 16:04, Vadim Pakhnushev <vadim.pakhnus...@oracle.com> 
> wrote:
> 
> On 06.03.2016 17:35, Hendrik Schreiber wrote:
>> hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev;cd jdk8u-dev;sh 
>> get_source.sh .
> Just remove the last dot, the script treats it as the path to the closed 
> repositories.

Thanks so much, Vadim! Works like a charm.

At the bottom of http://openjdk.java.net/projects/jdk8u it says:

The jdk8u-dev forest for ongoing development can be cloned using this command: 
hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev;cd jdk8u-dev;sh 
get_source.sh .

That last dot is the full stop of the sentence, and does not belong to the call.
The formatting is unfortunate and perhaps should be changed to save poor souls 
like me some time and keep me from asking stupid questions…

Cheers,

-hendrik

get_source.sh does not seem to work, fails on jdk/src/closed

[Hendrik Schreiber]

Hey there,

I’m trying to clone the repo on OS X and fetch the sources, but am failing 
miserably. This has worked before (8u20 or so), but now no such luck.

The output of what I do and see is pasted below.
Searching the bug database led to 
https://bugs.openjdk.java.net/browse/JDK-8056269

However, I can’t apply the mentioned workaround (using hg tconfig):

prompt>  hg tconfig --set --walk
hg: unknown command 'tconfig'

I’m sure there is a simple solution to this and hope you can point me in the 
right direction.

Thank you,

-hendrik


hg clone http://hg.openjdk.java.net/jdk8u/jdk8u-dev;cd jdk8u-dev;sh 
get_source.sh .
destination directory: jdk8u-dev
requesting all changes
adding changesets
adding manifests
adding file changes
added 1655 changesets with 2041 changes to 141 files
updating to branch default
85 files updated, 0 files merged, 0 files removed, 0 files unresolved
# Repositories:  corba jaxp jaxws langtools jdk hotspot nashorn  jdk/src/closed 
jdk/make/closed jdk/test/closed hotspot/make/closed hotspot/src/closed 
hotspot/test/closed deploy install sponsors pubs
corba:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/corba corba
 jaxp:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jaxp jaxp
corba:   requesting all changes
 jaxp:   requesting all changes
 jaxp:   adding changesets
corba:   adding changesets
corba:   adding manifests
 jaxp:   adding manifests
corba:   adding file changes
 jaxp:   adding file changes
corba:   added 1198 changesets with 4156 changes to 1388 files
corba:   updating to branch default
corba:   1194 files updated, 0 files merged, 0 files removed, 0 
files unresolved
jaxws:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jaxws jaxws
jaxws:   requesting all changes
jaxws:   adding changesets
jaxws:   adding manifests
jaxws:   adding file changes
 jaxp:   added 1252 changesets with 7312 changes to 4238 files
 jaxp:   updating to branch default
 jaxp:   2075 files updated, 0 files merged, 0 files removed, 0 
files unresolved
langtools:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/langtools langtools
langtools:   requesting all changes
langtools:   adding changesets
jaxws:   added 1083 changesets with 13077 changes to 6751 files
langtools:   adding manifests
jaxws:   updating to branch default
jaxws:   3734 files updated, 0 files merged, 0 files removed, 0 
files unresolved
  jdk:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk jdk
  jdk:   requesting all changes
  jdk:   adding changesets
langtools:   adding file changes
  jdk:   adding manifests
langtools:   added 3084 changesets with 21850 changes to 7172 files
langtools:   updating to branch default
langtools:   6374 files updated, 0 files merged, 0 files removed, 0 
files unresolved
  hotspot:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot hotspot
  hotspot:   requesting all changes
  hotspot:   adding changesets
  hotspot:   adding manifests
  hotspot:   adding file changes
  hotspot:   added 7819 changesets with 40729 changes to 5665 files
  hotspot:   updating to branch default
  hotspot:   4739 files updated, 0 files merged, 0 files removed, 0 
files unresolved
  nashorn:   hg clone 
http://hg.openjdk.java.net/jdk8u/jdk8u-dev/nashorn nashorn
  nashorn:   requesting all changes
  nashorn:   adding changesets
  nashorn:   adding manifests
  jdk:   adding file changes
  nashorn:   adding file changes
  nashorn:   added 1735 changesets with 10827 changes to 2959 files
  nashorn:   updating to branch default
  nashorn:   2742 files updated, 0 files merged, 0 files removed, 0 
files unresolved
   jdk/src/closed:   jdk/src still not created, waiting...
   jdk/src/closed:   jdk/src still not created, waiting...
   jdk/src/closed:   jdk/src still not created, waiting...
   jdk/src/closed:   jdk/src still not created, waiting...
  jdk:   added 11462 changesets with 96072 changes to 27163 
files
  jdk:   updating to branch default
   jdk/src/closed:   hg clone ./jdk8u/jdk8u-dev/jdk/src/closed 
jdk/src/closed
   jdk/src/closed:   abort: repository ./jdk8u/jdk8u-dev/jdk/src/closed not 
found!
  jdk/make/closed:   hg clone ./jdk8u/jdk8u-dev/jdk/make/closed