search

eclipse-openj9 / openj9

Eclipse OpenJ9: A Java Virtual Machine for OpenJDK that's optimized for small footprint, fast start-up, and high throughput. Builds on Eclipse OMR (https://github.com/eclipse/omr) and combines with the Extensions for OpenJDK for OpenJ9 repo.
Other
3.27k stars 720 forks source link

Windows compiles BytecodeInterpreter with no optimization #727

Closed pshipton closed 6 years ago

pshipton commented 6 years ago

Historically on Windows, trying to compile the BytecodeInterpreter with MSVC at max opt (/Ox) hangs. To work around this BytecodeInterpreter.cpp contains the following, causing this file to be compiled with global optimization disabled. This will have an undesirable affect on performance.

#if defined(_MSC_VER)
/* MSVC compiler hangs on this file at max opt (/Ox) */
#pragma optimize( "g", off )
#endif /* _MSC_VER */
DanHeidinga commented 6 years ago

Prior to open sourcing OpenJ9, IBM used mingw to compile the BytecodeInterpreter on Windows. We used a stripped down version of the stddef.h MSVC header.

There is only a single header file that is required to do this - stddef.h - which needs to be re-implemented to obtain a version of the "offsetof" macro. The macro isn't hard to write - one way to do this is to use the definition from a liberally licensed project like the musl c stdlib - https://github.com/cloudius-systems/musl/blob/master/include/stddef.h

The musl copyright statements indicate that the files in /include are either MIT (as a fallback) or public domain = https://github.com/cloudius-systems/musl/blob/master/COPYRIGHT

@pdbain-ibm Can you take a look at getting the OpenJ9 build process to be able to use mingw, and the musl's stddef.h, if mingw is available?

pdbain-ibm commented 6 years ago

Submitted https://github.com/eclipse/omr/pull/2170 which ifndef's out the dummy declaration of "__thiscall". Later releases of mingw define this symbol.

pshipton commented 6 years ago

Please identify the release of mingw being used.

pdbain-ibm commented 6 years ago

gcc version 6.4.0 (GCC).

However, the MSVC compiler on the OpenJ9 build machine doesn't like the object file generated: BytecodeInterpreter.obj : fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x6

Our lab machines run COLLECT_GCC=x86_64-w64-mingw32-g++ Target: x86_64-w64-mingw32 Configured with: ../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj-c++ --enable-fully-dynamic-string --disable-multilib Thread model: win32 gcc version 4.5.4 20110822 (prerelease) (GCC)

pshipton commented 6 years ago

Right I was just going to comment that you might need to stick with an older version for compatibility.

pdbain-ibm commented 6 years ago

We will need to get the OpenJ9 build machines reconfigured with the older version of mingw.

pdbain-ibm commented 6 years ago

@vsebe would you do the needful to install on the OpenJ9 build machines the same version of mingw as the vmfarm machines? Thanks

mleipe commented 6 years ago

@pdbain-ibm can you do it yourself by updating the Ansible playbook? @vsebe is away until the new year.

pdbain-ibm commented 6 years ago

Good plan. Could you tell where to find same? I had a look around https://github.com/AdoptOpenJDK/openjdk-build but, comments notwithstanding, there's no ansible directory.

mstoodle commented 6 years ago

@pdbain-ibm try looking in the openjdk-infrastructure repository

pdbain-ibm commented 6 years ago

Working on openjdk-infrastructure/ansible/playbooks/windows.yml. Commented out Windows Updates, Jenkins user, Firefox, Perl, Ant, Cuda, NTP, and pass/fail Slack tasks. Testing on a cloud-provisioned Windows 10 machine.

pdbain-ibm commented 6 years ago

Building per https://github.com/eclipse/openj9/blob/master/buildenv/Build_Instructions_V9.md#windows Ansible installs freemarker in a different place, so configure command is: $ bash configure --disable-warnings-as-errors --with-toolchain-version=2013 --with-freemarker-jar=/cygdrive/c/openjdk/freemarker.jar --with-freetype-src=/cygdrive/c/openjdk/freetype-2.5.3

pdbain-ibm commented 6 years ago

testfiles.zip Tried mingw and MSVC together in a trivial program: C:\cygwin64\home\Administrator\openj9>x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-6.4.0-2.x86_64/src/gcc-6.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw64-x86_64/mingw64-x86_64-gcc-6.4.0-2.x86_64/src/gcc-6.4.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/mingw64-x86_64-gcc --htmldir=/usr/share/doc/mingw64-x86_64-gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --without-libiconv-prefix --without-libintl-prefix --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-build-sysroot=/usr/x86_64-w64-mingw32/sys-root --disable-multilib --disable-win32-registry --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-fully-dynamic-string --enable-graphite --enable-libgomp --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-version-specific-runtime-libs --enable-libgomp --enable-libada --with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic --with-cloog-include=/usr/include/cloog-isl --with-system-zlib --enable-threads=posix --libexecdir=/usr/lib Thread model: posix gcc version 6.4.0 (GCC)

C:\cygwin64\home\Administrator\openj9>cl -v Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x64 Copyright (C) Microsoft Corporation. All rights reserved. Tested and working.

pdbain-ibm commented 6 years ago

Set compile option to -O0. failed. run "lib BytecodeInterpreter.obj". Failed. Ran lib on a lib BytecodeInterpreter.obj from an intrel. Passed. The symbol table from the passing file is 190 lines, the failing object file is ~6000 lines, mostly extra symbols.

Seems to be complaining about this: SECTION HEADER #5 /58 name (.xdata$_ZN19VM_ArrayCopyHelpers14copyForwardU64EPyS0_y) 0 physical address 0 virtual address 8 size of raw data 10D04 file pointer to raw data (00010D04 to 00010D0B) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40301040 flags Initialized Data COMDAT (no symbol) 4 byte align Read Only

RAW DATA #5 00000000: 01 04 02 05 04 03 01 50 .......P

SECTION HEADER #6 /113 name (.pdata$_ZN19VM_ArrayCopyHelpers14copyForwardU64EPyS0_y) 0 physical address 0 virtual address C size of raw data 10D0C file pointer to raw data (00010D0C to 00010D17) 5DDA8 file pointer to relocation table 0 file pointer to line numbers 3 number of relocations 0 number of line numbers 40301040 flags Initialized Data COMDAT (no symbol) 4 byte align Read Only

pdbain-ibm commented 6 years ago

Dumping it with objdump on my Mac: BytecodeInterpreter.bad: file format COFF-x86-64

SYMBOL TABLE: [ 0](sec -2)(fl 0x00)(ty 0)(scl 67) (nx 1) 0x00000000 .file AUX ^@^@^@^@<81>^A <<<< looks bogus [ 2](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text$_ZN7JNIEnv_14ExceptionClearEv AUX scnlen 0x27 nreloc 0 nlnno 0 checksum 0x0 assoc 0 comdat 2 [ 4](sec 4)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x00000000 _ZN7JNIEnv_14ExceptionClearEv AUX Unknown <<<< Also unexpected. [ 6](sec 7)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x00000000 .text$_ZN7JNIEnv_17GetStringUTFCharsEP8_jstringPh AUX scnlen 0x39 nreloc 0 nlnno 0 checksum 0x0 assoc 0 comdat 2 [ 8](sec 7)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _ZN7JNIEnv_17GetStringUTFCharsEP8_jstringPh

pdbain-ibm commented 6 years ago

Looked at using the mingw compiler to generate assembler, but ml64 won't take it. Disabled USE_COMPUTED_GOTO. Same problem. Disabled VMINLINE. same problem. Tried the following compiler options:

-fvisibility-ms-compat \ -fvisibility-inlines-hidden \ -fabi-version=2 \ -Fno-weak \ -fvisibility=hidden \

pshipton commented 6 years ago

Older versions of gcc can be installed, is there any reason not to use gcc 4.x, which should be compatible?

> mingw32-g++ --version
mingw32-g++ (GCC) 4.9.3
dnakamura commented 6 years ago

@pdbain-ibm The issue appears to be caused by gcc adding SEH handling data for functions which may be externally reachable (ie the symbols in the .pdata and .xdata sections). Passing -fno-asynchronous-unwind-tables seems to fix the issue

pdbain-ibm commented 6 years ago

That did the trick. I can now compile and link with gcc 6.4.0.

pdbain-ibm commented 6 years ago

Marius Pirvu writes: I tested your build with two Liberty workloads 1) With tradeliteServer I measured a 0.8% startup regression with your build, but the difference in absolute terms is so small (1403 vs 1392) that this may be just fluctuation 2) With DT3 there is no startup regression. I would say we are good.

charliegracie commented 6 years ago

Did anyone look at the generated code for BytecodeInterpreter.o specifically around the main loop and compare the code generated for executing the next bytecode?

pshipton commented 6 years ago

@pdbain-ibm are you able to address Charlie's comment to complete these issue so it can be closed?

pdbain-ibm commented 6 years ago

I discussed this with @charliegracie . Since we are using the mingw compiler, which is known to produce good code in this situation, and since Marius Pirvu benchmarked the generated code, he has no further concerns.

pshipton commented 6 years ago

In that case we can close this issue. mingw was enabled by https://github.com/ibmruntimes/openj9-openjdk-jdk8/pull/37 https://github.com/ibmruntimes/openj9-openjdk-jdk9/pull/116