Do we have an outlook for starting this?

irinarada on 5 Jun 2018

I will check it out to see how to get this work.

ChengJin01 on 10 Jun 2018

👍1

After fixing the setting issues with jre-image, paths to MSVC, etc, I am currently working on other issues in config/mk scripts captured during compilation.

ChengJin01 on 14 Jun 2018

Currently it ended up with linking failure on unresolved external symbols as follows:

x86_64-w64-mingw32-g++ -O3 -DWIN32 -D_WIN32 -DOMR_OS_WINDOWS -D_AMD64_=1 -DWIN64 -D_WIN64 -DJ9HAMMER -D_CRT_SECURE_NO_WARNINGS -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -D_WIN95 -D_WIN32_WINDOWS=0x0500 -D_WIN32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_MT -D_WINSOCKAPI_ -D_DLL -I. -I../include -I../oti -I../util -I../gc_include -I../omr/gc/include -I../shared_common/include -I../gc_glue_java -I../nls -I../omr/include_core  -I../oti/mingw   -mdll -mwin32 -mthreads -fno-rtti -fno-threadsafe-statics -fno-strict-aliasing -fno-exceptions -fno-use-linker-plugin -fno-asynchronous-unwind-tables -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c BytecodeInterpreter.cpp -o BytecodeInterpreter.obj
...
link  /debug  /opt:icf /opt:ref /INCREMENTAL:NO /NOLOGO  -entry:_DllMainCRTStartup -dll  -machine:AMD64 \
  -subsystem:console -out:../j9vm29.dll -map:j9vm.map \
   copyright.obj AsyncMessageHandler.obj BytecodeInterpreter.obj ClassInitialization.obj DebugBytecodeInterpreter.obj
...
BytecodeInterpreter.obj : error LNK2019: unresolved external symbol __imp___iob_func referenced in function _ZN22VM_BytecodeInterpreter3runEP10J9VMThread
DebugBytecodeInterpreter.obj : error LNK2001: unresolved external symbol __imp___iob_func
MHInterpreter.obj : error LNK2001: unresolved external symbol __imp___iob_func
../j9vm29.dll : fatal error LNK1120: 1 unresolved externals

It seems the failure was triggered when linking (VS2017) the .obj files (compiled by mingw) with non-existent functions in libraries in VS2017 (___iob_func was already renamed to acrt_iob_func since VS2015)

Here's typical explanations online of what happens to "unresolved external symbol __imp___iob_func"
[1] https://stackoverflow.com/questions/30412951/unresolved-external-symbol-imp-fprintf-and-imp-iob-func-sdl2
[2] https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT

There are a bunch of discussions on "unresolved external symbol __imp___iob_func" but none of them works for our case (tried with legacy_stdio_definitions.lib but didn't work. might be in the wrong way?)

I am wondering whether it is possible to get the linker (VS2017) to pick up the static libraries ( __imp___iob_func) supported in mingw.

ChengJin01 on 15 Jun 2018

We can try compiling the BytecodeInterpreter with VS2017 instead of mingw. Perhaps it will work, even though 2010 and 2013 do not.

As I recall 2010 and 2013 can't compile BytecodeInterpreter with optimization enabled. It compiles with -O0 but then we have stack related problems at runtime.

pshipton on 15 Jun 2018

THe issue is that by default the new VS uses a bunch of inlined functions for CRT functions, but mingw doesnt pick them up. IIRC this can be fixed by setting the VS12AndHigher flag in the buildspec.
@pshipton it will compile with 2017, but with optimizations disabled. (enabling still results in a hang)

dnakamura on 15 Jun 2018

👍2

To verify the suggestion above, I made the following changes:

1) /buildspecs/win_x86-64_cmprssptrs.spec
    <flags>
        <flag id="build_VS12AndHigher" value="true"/>  <--- enable VS12AndHigher
2) /runtime/makelib/targets.mk.win.inc.ftl
CFLAGS+=$(UMA_OPTIMIZATION_FLAGS)
CXXFLAGS+=$(UMA_OPTIMIZATION_FLAGS)
ifdef USE_MINGW
    ifdef VS12AndHigher  (already set up in /runtime/makelib/mkconstants.mk.ftl)
        MINGW_CXXFLAGS+=-O0  <----- optimization disabled
    else
        MINGW_CXXFLAGS+=-O3
    endif
endif

However, it still ended up with the same linking failures as follows:

x86_64-w64-mingw32-g++ -O0 -DWIN32 -D_WIN32 -DOMR_OS_WINDOWS -D_AMD64_=1 -DWIN64 -D_WIN64 -DJ9HAMMER -D_CRT_SECURE_NO_WARNINGS -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -D_WIN95 -D_WIN32_WINDOWS=0x0500 -D_WIN32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_MT -D_WINSOCKAPI_ -D_DLL -I. -I../include -I../oti -I../util -I../gc_include -I../omr/gc/include -I../shared_common/include -I../gc_glue_java -I../nls -I../omr/include_core  -I../oti/mingw   -mdll -mwin32 -mthreads -fno-rtti -fno-threadsafe-statics -fno-strict-aliasing -fno-exceptions -fno-use-linker-plugin -fno-asynchronous-unwind-tables -std=c++0x -D_CRT_SUPPRESS_RESTRICT -DVS12AndHigher -D_M_X64 -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c BytecodeInterpreter.cpp -o BytecodeInterpreter.obj
x86_64-w64-mingw32-g++ -O0 -DWIN32 -D_WIN32 -DOMR_OS_WINDOWS -D_AMD64_=1 -DWIN64 -D_WIN64 -DJ9HAMMER -D_CRT_SECURE_NO_WARNINGS -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -D_WIN95 -D_WIN32_WINDOWS=0x0500 -D_WIN32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_MT -D_WINSOCKAPI_ -D_DLL -I. -I../include -I../oti -I../util -I../gc_include -I../omr/gc/include -I../shared_common/include -I../gc_glue_java -I../nls -I../omr/include_core  -I../oti/mingw   -mdll -mwin32 -mthreads -fno-rtti -fno-threadsafe-statics -fno-strict-aliasing -fno-exceptions -fno-use-linker-plugin -fno-asynchronous-unwind-tables -std=c++0x -D_CRT_SUPPRESS_RESTRICT -DVS12AndHigher -D_M_X64 -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c DebugBytecodeInterpreter.cpp -o DebugBytecodeInterpreter.obj
In file included from BytecodeInterpreter.hpp:41:0,
                 from BytecodeInterpreter.cpp:94,
                 from DebugBytecodeInterpreter.cpp:25:
../include/ffi.h:85:0: warning: "LONG_LONG_MAX" redefined
 #   define LONG_LONG_MAX __LONG_LONG_MAX__

In file included from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:168:0,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:34,
                 from ../include/ffi.h:76,
                 from BytecodeInterpreter.hpp:41,
                 from BytecodeInterpreter.cpp:94,
                 from DebugBytecodeInterpreter.cpp:25:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/limits.h:63:0: note: this is the location of the previous definition
 #define LONG_LONG_MAX 9223372036854775807ll

In file included from BytecodeInterpreter.hpp:41:0,
                 from BytecodeInterpreter.cpp:94:
../include/ffi.h:85:0: warning: "LONG_LONG_MAX" redefined
 #   define LONG_LONG_MAX __LONG_LONG_MAX__

In file included from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:168:0,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:34,
                 from ../include/ffi.h:76,
                 from BytecodeInterpreter.hpp:41,
                 from BytecodeInterpreter.cpp:94:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/limits.h:63:0: note: this is the location of the previous definition
 #define LONG_LONG_MAX 9223372036854775807ll

x86_64-w64-mingw32-g++ -O0 -DWIN32 -D_WIN32 -DOMR_OS_WINDOWS -D_AMD64_=1 -DWIN64 -D_WIN64 -DJ9HAMMER -D_CRT_SECURE_NO_WARNINGS -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -D_WIN95 -D_WIN32_WINDOWS=0x0500 -D_WIN32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_MT -D_WINSOCKAPI_ -D_DLL -I. -I../include -I../oti -I../util -I../gc_include -I../omr/gc/include -I../shared_common/include -I../gc_glue_java -I../nls -I../omr/include_core  -I../oti/mingw   -mdll -mwin32 -mthreads -fno-rtti -fno-threadsafe-statics -fno-strict-aliasing -fno-exceptions -fno-use-linker-plugin -fno-asynchronous-unwind-tables -std=c++0x -D_CRT_SUPPRESS_RESTRICT -DVS12AndHigher -D_M_X64 -DUT_DIRECT_TRACE_REGISTRATION -DTR_HOST_X86 -c MHInterpreter.cpp -o MHInterpreter.obj
In file included from MHInterpreter.hpp:26:0,
                 from MHInterpreter.cpp:29:
../include/ffi.h:85:0: warning: "LONG_LONG_MAX" redefined
 #   define LONG_LONG_MAX __LONG_LONG_MAX__

In file included from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:168:0,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/syslimits.h:7,
                 from /usr/lib/gcc/x86_64-w64-mingw32/6.4.0/include-fixed/limits.h:34,
                 from ../include/ffi.h:76,
                 from MHInterpreter.hpp:26,
                 from MHInterpreter.cpp:29:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/limits.h:63:0: note: this is the location of the previous definition
 #define LONG_LONG_MAX 9223372036854775807ll

lib -subsystem:console -out:../lib/j9vm.lib -def:j9vm.def -machine:AMD64 copyright.obj AsyncMessageHandler.obj BytecodeInterpreter.obj ClassInitialization.obj DebugBytecodeInterpreter.obj FFITypeHelpers.obj FastJNI.obj FastJNI_com_ibm_oti_vm_VM.obj FastJNI_java_lang_Class.obj FastJNI_java_lang_ClassLoader.obj FastJNI_java_lang_J9VMInternals.obj FastJNI_java_lang_Object.obj FastJNI_java_lang_String.obj FastJNI_java_lang_System.obj FastJNI_java_lang_Thread.obj FastJNI_java_lang_Throwable.obj FastJNI_java_lang_invoke_MethodHandle.obj FastJNI_java_lang_ref_Reference.obj FastJNI_java_lang_reflect_Array.obj FastJNI_sun_misc_Unsafe.obj FlushProcessWriteBuffers.obj J9OMRHelpers.obj KeyHashTable.obj MHInterpreter.obj ModularityHashTables.obj NativeHelpers.obj ObjectFieldInfo.obj ObjectMonitor.obj OutOfLineINL_com_ibm_jit_JITHelpers.obj OutOfLineINL_java_lang_invoke_NativeMethodHandle.obj OutOfLineINL_jdk_internal_misc_Unsafe.obj StackDumper.obj VMAccess.obj annsup.obj bchelper.obj bindnatv.obj callin.obj classallocation.obj classloadersearch.obj classseg.obj classsupport.obj createramclass.obj description.obj dllsup.obj drophelp.obj exceptiondescribe.obj exceptionsupport.obj findmethod.obj gphandle.obj growstack.obj guardedstorage.obj hookableAsync.obj initsendtarget.obj intfunc.obj j9dll.obj j9vm.res javaPriority.obj jnicgen.obj jnicsup.obj jnifield.obj jniinv.obj jnimem.obj jnimisc.obj jnireflect.obj jvmfree.obj jvminit.obj jvminitcommon.obj jvmrisup.obj linearswalk.obj lockwordconfig.obj logsupport.obj lookuphelper.obj lookupmethod.obj monhelpers.obj montable.obj ownedmonitors.obj profilingbc.obj rasdump.obj rastrace.obj resolvefield.obj resolvesupport.obj romclasses.obj romutil.obj segment.obj stackswap.obj statistics.obj stringhelpers.obj swalk.obj threadhelp.obj threadpark.obj throwexception.obj ut_j9vm.obj visible.obj vmbootlib.obj vmhook.obj vmifunc.obj vmizip.obj vmphases.obj vmprops.obj vmruntimestate.obj vmthinit.obj vmthread.obj xcheck.obj xcinterp.obj  ../lib/j9thr.lib ../lib/j9hookable.lib ../lib/j9prt.lib ../lib/omrsig.lib  ../lib/j9verutil.lib ../lib/j9util.lib ../lib/j9utilcore.lib ../lib/j9stackmap.lib ../lib/j9bcv.lib ../lib/j9dyn.lib ../lib/j9simplepool.lib ../lib/j9zip.lib ../lib/ffi.lib ../lib/j9avl.lib ../lib/j9hashtable.lib ../lib/j9pool.lib ../lib/j9omr.lib
Microsoft (R) Library Manager Version 14.14.26430.0
Copyright (C) Microsoft Corporation.  All rights reserved.

   Creating library ../lib/j9vm.lib and object ../lib/j9vm.exp
../makelib/targets.mk:476: UMA_SINGLE_REBASE specified, suppressing per-directory rebase.
link  /debug  /opt:icf /opt:ref /INCREMENTAL:NO /NOLOGO  -entry:_DllMainCRTStartup -dll  -machine:AMD64 \
  -subsystem:console -out:../j9vm29.dll -map:j9vm.map \
   copyright.obj AsyncMessageHandler.obj BytecodeInterpreter.obj ClassInitialization.obj DebugBytecodeInterpreter.obj FFITypeHelpers.obj FastJNI.obj FastJNI_com_ibm_oti_vm_VM.obj FastJNI_java_lang_Class.obj FastJNI_java_lang_ClassLoader.obj FastJNI_java_lang_J9VMInternals.obj FastJNI_java_lang_Object.obj FastJNI_java_lang_String.obj FastJNI_java_lang_System.obj FastJNI_java_lang_Thread.obj FastJNI_java_lang_Throwable.obj FastJNI_java_lang_invoke_MethodHandle.obj FastJNI_java_lang_ref_Reference.obj FastJNI_java_lang_reflect_Array.obj FastJNI_sun_misc_Unsafe.obj FlushProcessWriteBuffers.obj J9OMRHelpers.obj KeyHashTable.obj MHInterpreter.obj ModularityHashTables.obj NativeHelpers.obj ObjectFieldInfo.obj ObjectMonitor.obj OutOfLineINL_com_ibm_jit_JITHelpers.obj OutOfLineINL_java_lang_invoke_NativeMethodHandle.obj OutOfLineINL_jdk_internal_misc_Unsafe.obj StackDumper.obj VMAccess.obj annsup.obj bchelper.obj bindnatv.obj callin.obj classallocation.obj classloadersearch.obj classseg.obj classsupport.obj createramclass.obj description.obj dllsup.obj drophelp.obj exceptiondescribe.obj exceptionsupport.obj findmethod.obj gphandle.obj growstack.obj guardedstorage.obj hookableAsync.obj initsendtarget.obj intfunc.obj j9dll.obj j9vm.res javaPriority.obj jnicgen.obj jnicsup.obj jnifield.obj jniinv.obj jnimem.obj jnimisc.obj jnireflect.obj jvmfree.obj jvminit.obj jvminitcommon.obj jvmrisup.obj linearswalk.obj lockwordconfig.obj logsupport.obj lookuphelper.obj lookupmethod.obj monhelpers.obj montable.obj ownedmonitors.obj profilingbc.obj rasdump.obj rastrace.obj resolvefield.obj resolvesupport.obj romclasses.obj romutil.obj segment.obj stackswap.obj statistics.obj stringhelpers.obj swalk.obj threadhelp.obj threadpark.obj throwexception.obj ut_j9vm.obj visible.obj vmbootlib.obj vmhook.obj vmifunc.obj vmizip.obj vmphases.obj vmprops.obj vmruntimestate.obj vmthinit.obj vmthread.obj xcheck.obj xcinterp.obj  ../lib/j9thr.lib ../lib/j9hookable.lib ../lib/j9prt.lib ../lib/omrsig.lib  ../lib/j9verutil.lib ../lib/j9util.lib ../lib/j9utilcore.lib ../lib/j9stackmap.lib ../lib/j9bcv.lib ../lib/j9dyn.lib ../lib/j9simplepool.lib ../lib/j9zip.lib ../lib/ffi.lib ../lib/j9avl.lib ../lib/j9hashtable.lib ../lib/j9pool.lib ../lib/j9omr.lib kernel32.lib ws2_32.lib advapi32.lib user32.lib gdi32.lib comdlg32.lib winspool.lib \
   ../lib/j9vm.exp
BytecodeInterpreter.obj : error LNK2019: unresolved external symbol __imp___iob_func referenced in function _ZN22VM_BytecodeInterpreter15i2jMHTransitionERPyRPh
DebugBytecodeInterpreter.obj : error LNK2001: unresolved external symbol __imp___iob_func
MHInterpreter.obj : error LNK2001: unresolved external symbol __imp___iob_func
../j9vm29.dll : fatal error LNK1120: 1 unresolved externals
make[5]: *** [../makelib/targets.mk:475: ../j9vm29.dll] Error 96
make[5]: Leaving directory '/cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/vm/vm'
make[4]: *** [makefile:146: j9vm] Error 2
make[4]: Leaving directory '/cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/vm'
make[3]: *** [/cygdrive/c/temp/openj9-openjdk-jdk/closed/OpenJ9.gmk:387: build-j9] Error 2
make[2]: *** [/cygdrive/c/temp/openj9-openjdk-jdk/closed/make/Main.gmk:40: j9vm-build] Error 2
make[2]: *** Waiting for unfinished jobs....

The failures shows -O0 and -DVS12AndHigher were already set up for x86_64-w64-mingw32-g++ and it works in some way but it didn't help to get these obj file linked correctly.

My understanding is that mingw does pick up the inlined CRT functions (the error above is kind of different from previous one) but it is unable to replace __imp___iob_func with the renamed acrt_iob_func or it can't find acrt_iob_func in its own lib path during compilation.

Double-checked BytecodeInterpreter.obj with dumpbin.exe tool.
It shows __imp___iob_func is still there and there is no acrt_iob_func found in the obj file:

6F9 00000000 SECT24D notype       External    | .refptr.omrthread_monitor_notify
6FA 00000000 UNDEF  notype       External     | __imp___iob_func <-----

ChengJin01 on 16 Jun 2018

Also checked the directories of mingw but acrt_iob_func doesn't exist:

./sys-root/mingw/include/stdio.h:  _CRTIMP FILE *__cdecl __iob_func(void);
./sys-root/mingw/include/stdio.h:#define _iob  __iob_func()
./sys-root/mingw/include/stdio.h:#define __iob_func()   (_iob)
./sys-root/mingw/include/stdio.h:#define __iob_func()   (* __MINGW_IMP_SYMBOL(_iob))
./sys-root/mingw/include/stdio.h:#define _iob __iob_func()
./sys-root/mingw/include/stdio.h:#define stdin (&__iob_func()[0])
./sys-root/mingw/include/stdio.h:#define stdout (&__iob_func()[1])
./sys-root/mingw/include/stdio.h:#define stderr (&__iob_func()[2])

ChengJin01 on 16 Jun 2018

@pshipton it will compile with 2017, but with optimizations disabled. (enabling still results in a hang)

An aside have we thought of taking advantage now that we're open source to file a bug report with Microsoft [1] on this one so it can be fixed in a future release?

[1] https://docs.microsoft.com/en-us/cpp/how-to-report-a-problem-with-the-visual-cpp-toolset

fjeremic on 16 Jun 2018

The best case is that mingw guys upgrade their code to keep up with the stdio-related changes in VS2015/2017. However, they didn't do that as they didn't expect we to compile the code in this way.

ChengJin01 on 16 Jun 2018

file a bug report with Microsoft

I think @charliegracie was in communication at one point, not sure if we got as far as filing a bug.

pshipton on 16 Jun 2018

The situation is quite similar to compiling code with an earlier version of VS (VS2010) and linking them via VS2015/2017, which most users encountered in their projects as discussed on websites.
Under such circumstance, the only solution to this issue suggested by Microsoft at https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT is to compile the whole project with VS2015/2017 or modify the code involved to create a new DLL to encapsulate the usage of the library if technically possible.

<stdio.h> and <conio.h>
... ...
If your project links with static libraries that were compiled with a release of Visual C++ earlier than 2015,
the linker might report an unresolved external symbol. These errors might reference internal stdio 
definitions for _iob, _iob_func, or related imports for certain stdio functions in the form of _imp_*. 
Microsoft recommends that you recompile all static libraries with the latest version of the Visual C++
compiler and libraries when you upgrade a project. If the library is a third-party library for which source 
is not available, you should either request an updated binary from the third party or encapsulate your 
usage of that library into a separate DLL that you compile with the older version of the Visual C++ 
compiler and libraries.

ChengJin01 on 16 Jun 2018

Currently the build is compiled on Windows 7 in which mingw still sticks with an older version of CRT.

The link from Microsoft at https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx says:

The CRT Library has been refactored into a two different binaries, a Universal CRT (ucrtbase), which contains most of the standard functionality, and a VC Runtime Library (vcruntime140), which contains the compiler-related functionality, such as exception handling, and intrinsics.

In Visual Studio 2015, the CRT has been refactored into new binaries. 
The Universal CRT (UCRT) contains the functions and globals exported by the standard C99 CRT library. 
The UCRT is now a Windows component, and ships as part of Windows 10. 
The static library, DLL import library, and header files for  the UCRT are now found in the Windows 10 
SDK.

The website of mingw-w64 at https://mingw-w64.org/doku.php#mingw-w64
shows the latest version already provides support on Windows 10 and UCRT in stdio.h

https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/stdio.h
#define stdin (__acrt_iob_func(0))
#define stdout (__acrt_iob_func(1))
#define stderr (__acrt_iob_func(2))
#endif

Given that the stuff with "stdio.h" was categorized to UCRT since VS2015, it might be worthy to try installing Cygwin with the latest mingw-w64 packages + VS2017 (plus Windows 10 SDK ? ) on Windows 10 to see whether mingw-w64 compile our code with UCRT.

ChengJin01 on 17 Jun 2018

It turns out the mingw64 package specified in cygwin is still an older version without UCRT support.
So I need to:
1) reinstall cygwin without mingw64 package
2) download the source from https://github.com/mirror/mingw-w64/ and manually configure everything in mingw64 for UCRT to see whether it works.
or 3) install from https://sourceforge.net/projects/mingw-w64/files/?source=navbar

ChengJin01 on 17 Jun 2018

The new version of x86_64-w64-mingw32-g++ works good on in terms of compiling BytecodeInterpreter.cpp, DebugBytecodeInterpreter.cpp and MHInterpreter.cpp on Win 7 after installing the latest version of mingw64 downloaded from https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe

So the root cause is that the latest cgywin didn't pick up the new version of mingw64 (which already supports UCRT). The way around this issue is to update our config/setting file (e.g./runtime/makelib/mkconstants.mk.ftl) to point to the new version of mingw64 (which is installed separately/outside of cygwin dir) rather than the outdated one installed in cygwin by default. (Note: the problem has nothing to do with Windows 10)

Will keep investigating as there are still other issues during compilation.

ChengJin01 on 17 Jun 2018

I think @charliegracie was in communication at one point, not sure if we got as far as filing a bug.
I think he sent then the prepossessed interpreter and they just laughed and said no.

dnakamura on 18 Jun 2018

Currently investigating the error related to ddrgen.
The backtrace below shows it failed to locate the offset type when parsing these .pdf files as follows:

../ddrgen --blob ../j9ddr.dat --superset ../superset.dat --blacklist blacklist --macrolist ../macroList --overrides overrides --show-empty  \
        ../j9ddr_misc29.pdb ../j9gc29.pdb ../j9jvmti29.pdb ../j9prt29.pdb ../j9shr29.pdb ../j9thr29.pdb ../j9trc29.pdb ../j9vm29.pdb ../jclse11_29.pdb
Error: pdb/PdbScanner.cpp:640 PdbScanner::setMemberOffset - Unknown offset type: 10, name: invalidByteCodeIndex
make[5]: *** [run_omrddrgen.mk:73: ../j9ddr.dat] Error 1
make[5]: Leaving directory '/cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/vm/ddr'

0:002> ~* k
   0  Id: 46f0.18d0 Suspend: 1 Teb: 000007ff`fffde000 Unfrozen
Child-SP          RetAddr           Call Site
00000000`0030ea20 00000001`3f32442d ddrgen!PdbScanner::setMemberOffset+0x160 [pdb\pdbscanner.cpp @ 642]
00000000`0030ea80 00000001`3f324d4a ddrgen!PdbScanner::addSymbol+0x13d [pdb\pdbscanner.cpp @ 1291]
00000000`0030eb20 00000001`3f325b03 ddrgen!PdbScanner::addChildrenSymbols+0x3da [pdb\pdbscanner.cpp @ 354]
00000000`0030ec30 00000001`3f3243e2 ddrgen!PdbScanner::createClassUDT+0x533 [pdb\pdbscanner.cpp @ 1191]
00000000`0030edc0 00000001`3f324d4a ddrgen!PdbScanner::addSymbol+0xf2 [pdb\pdbscanner.cpp @ 1288]
00000000`0030ee60 00000001`3f322709 ddrgen!PdbScanner::addChildrenSymbols+0x3da [pdb\pdbscanner.cpp @ 354] <---SymTagUDT
00000000`0030ef70 00000001`3f2f1b09 ddrgen!PdbScanner::startScan+0x1a9 [pdb\pdbscanner.cpp @ 149]
00000000`0030f010 00000001`3f342b18 ddrgen!main+0x289 [\vm\omr\ddr\tools\ddrgen\ddrgen.cpp @ 131]
00000000`0030fa10 00000000`773a59cd ddrgen!__scrt_common_main_seh+0x10c [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 283]
00000000`0030fa50 00000000`7750383d kernel32!BaseThreadInitThunk+0xd
00000000`0030fa80 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

e.g. for j9ddr_misc29.pdb

ddrgen --blob ../j9ddr.dat --superset ../superset.dat --blacklist blacklist --macrolist ../macroList --overrides overrides --show-empty  ../j9ddr_misc29.pdb (FAILED)
Error: pdb/PdbScanner.cpp:644 PdbScanner::setMemberOffset - Unknown offset type: 10, name: invalidByteCodeIndex

Comparing the printing messages (from ddrgen) of j9ddr_misc29.pdb created by VS2010 and VS2017 suggests that the existing code in PdbScanner.cpp might have problem in dealing with the case of the nested SymTagUDT (only occurs in VS2017) or something new was generated in j9ddr_misc29.pdb.

ChengJin01 on 20 Jun 2018

@keithc-ca fyi https://github.com/eclipse/openj9/issues/1697#issuecomment-398613633

pshipton on 20 Jun 2018

Here're the results from j9gc29.pdb and j9thr29.pdb:

1) ddrgen --blob ../j9ddr.dat --superset ../superset.dat --blacklist blacklist --macrolist ../macroList --overrides overrides --show-empty  ../j9gc29.pdb
Error: pdb/PdbScanner.cpp:644 PdbScanner::setMemberOffset - Unknown offset type: 10, name: _FNV_prime

2) ddrgen --blob ../j9ddr.dat --superset ../superset.dat --blacklist blacklist --macrolist ../macroList --overrides overrides --show-empty  ../j9thr29.pdb 
Error: pdb/PdbScanner.cpp:644 PdbScanner::setMemberOffset - Unknown offset type: 10, name: _FNV_prime

I didn't find any file containing "_FNV_prime" in the build compiled via VS2010 while there are a bunch of .pdb files containing _FNV_prime (including j9thr29.pdb, j9thr29.pdb) in the build compiled by VS2017. If so, I am wondering whether the new type name needs to be added in a certain config/setting file in ddrgen/pdbscanner or the existing code in setMemberOffset() should address the case.

ChengJin01 on 20 Jun 2018

Error: pdb/PdbScanner.cpp:644 PdbScanner::setMemberOffset - Unknown offset type: 10, name: invalidByteCodeIndex

According to [1], offset type 10 is LocIsConstant.

An offending field is

   static const int32_t invalidByteCodeIndex =  -1;

Perhaps we need to check whether a field is static before worrying about its offset.

[1] https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/locationtype
[2] https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/idiasymbol-get-locationtype

keithc-ca on 20 Jun 2018

The problem is it returns LocIsConstant for both "const" and "static const" variables, in which case there is no easy way to tell whether the current field is static or not.

ChengJin01 on 20 Jun 2018

Can you give an example of a non-static field where that happens?

keithc-ca on 20 Jun 2018

1) e.g. I_32 minAOT;
it shows in superset.dat:
F|minAOT|minAOT|I32|I32

2) e.g. const UDATA _maxObjectCount;
it shows in superset.dat:
F|_maxObjectCount|_maxObjectCount|U64|const U64

ChengJin01 on 20 Jun 2018

Those fields certainly have 'const' type, but they are not compile-time constants so I would not expect offset type LocIsConstant. Is that what you're seeing?

keithc-ca on 20 Jun 2018

I double-checked the superset.dat generated via VS2010 and VS2017 and it turns out
it returns LocIsStatic for "static const" variables on VS2010
it returns LocIsConstant for "static const" variables on VS2017

e.g. static const int32_t invalidByteCodeIndex = -1;
it returns LocIsStatic on VS2010
superset.dat: F|invalidByteCodeIndex|invalidByteCodeIndex|I32|const I32

That means "static" is just ignored when calling get_locationType in the case of "const static" variables.

ChengJin01 on 20 Jun 2018

As for a "const" variable definition, e.g. const uint32_t categoryCode;
It shows in superdat:
F|categoryCode|categoryCode|U32|const U32

It means it returns something else (e.g. LocIsThisRel, LocIsBitField, etc) for "const" variables instead of LocIsConstant. If so, the field must be a static if it returns LocIsConstant (Correct me if wrong).

Then we can safely change the code to:

PdbScanner::setMemberOffset(IDiaSymbol *symbol, Field *newField)
{
...
        case LocIsStatic:  //fall through
        case LocIsConstant :  <------------
        {
            /* Get offset of static class members. */
            newField->_isStatic = true;
                ... ...

ChengJin01 on 20 Jun 2018

superset.dat is produced by ddrgen. I'm asking for an example non-static field for which PdbScanner would encounter offset type LocIsConstant, thereby preventing the creation of superset.dat.

FYI, static fields don't appear in superset.dat at all.

keithc-ca on 20 Jun 2018

I didn't find a "non-static field for which PdbScanner would encounter offset type LocIsConstant".
If it returns LocIsConstant, then it fails. The first field captured is "invalidByteCodeIndex" which is a "static const" variable.

ChengJin01 on 20 Jun 2018

LocIsConstant_pdb_files.txt
I double-checked these fields which returns LocIsConstant by adding printing messages in code but none of them is a non-static. (only "static const" for C/C++ and "static final" for Java are detected)

ChengJin01 on 20 Jun 2018

Good. Then all that needs to be done is to add a case in PdbScanner::setMemberOffset that handles LocIsConstant by setting newField->_isStatic = true; and probably not much more.

keithc-ca on 20 Jun 2018

I already tried this way:

PdbScanner::setMemberOffset(IDiaSymbol *symbol, Field *newField)
{
...
        case LocIsStatic:  //fall through
        case LocIsConstant :  <------------
        {
            /* Get offset of static class members. */
            newField->_isStatic = true;
                ... ...

and it ended up with the same results in superset.dat as VS2010:
F|invalidByteCodeIndex|invalidByteCodeIndex|I32|const I32, which is correct in our case (formal code review will be submitted once all issues with VS2017 get resolved)

So there is no issue with LocIsConstant with the fix above (already confirmed after recompiling the whole build)

ChengJin01 on 20 Jun 2018

Currently the compilation fails at omrcfg.h and j9cfg.h when generating jvmtitest.res as follows:
```
rc -I. -I../../tests/jvmtitests/include -I../../include -I../../oti
-I../../nls -I../../omr/include_core jvmtitest.rc

../../omr/include_coreomrcfg.h(252) : error RC2018: unknown character '0x40'
../../omr/include_coreomrcfg.h(252) : error RC2142: ellipsis requires three periods
../../omr/include_coreomrcfg.h(253) : error RC2018: unknown character '0x40'
...
../../omr/include_coreomrcfg.h(392) : error RC2142: ellipsis requires three periods

../../includej9cfg.h(292) : error RC2018: unknown character '0x40'
../../includej9cfg.h(292) : error RC2142: ellipsis requires three periods
../../includej9cfg.h(293) : error RC2018: unknown character '0x40'
../../includej9cfg.h(295) : error RC2018: unknown character '0x40'
../../includej9cfg.h(512) : error RC2018: unknown character '0x40'
...
../../includej9cfg.h(517) : error RC2018: unknown character '0x40'
../../includej9cfg.h(517) : fatal error RC1003: error count exceeds 100; stopping compilation
make[7]: [../../makelib/targets.mk:388: jvmtitest.res] Error 102 (ignored)

../../makelib/targets.mk

compilation rule for resource files.

%.res: %.rc
$(RC) $(UMA_RC_OPTIONS) $< <---- [../../makelib/targets.mk:388: jvmtitest.res] Error 102
````

jvmtitest.rc:

include

include "j9cfg.h" <----------- (#include "omrcfg.h" in j9cfg.h)

include "j9version.h"

VS_VERSION_INFO VERSIONINFO
FILEVERSION 2,9,0,0
PRODUCTVERSION 2,9,0,0

Given that these lines literally don't exist in the generated header files, it seems like there might be some problem with RC.

ChengJin01 on 22 Jun 2018

The getmacros script rewrites all header files adding a bunch of lines that begin with @. The build dependencies are intended to ensure that steps like running rc occur before getmacros begins; I suspect we're missing some of those dependencies.

BTW, I've been thinking there ought to be a way to restructure the build flow involving constant discovery that doesn't involve modifying the source header files, but one of the challenges is to work out an include path that works for producing *.i files in the presence of #include directives using "..." instead of <...>. Until then we'll have to arrange that no compiles can occur in parallel with getmacros.

keithc-ca on 22 Jun 2018

I am away on vacation next week and will be back to clean up the remaining issues on JDK11 with VS2017.

For the moment, the issues that were already fixed cover script/code bugs in JDK11, OpenJ9 and OMR (not yet submitted for review, depending on the final result of compilation and how many issues left to be fixed):
1) JDK11:
https://github.com/ChengJin01/openj9-openjdk-jdk/commit/313973a59a5e69e0ee2e6b85bf936d7b965b80cf
Note: CoreLibraries.gmk copied with minor changes to specify the source of libjava: LIBJAVA_SRC_DIRS += $(call FindSrcDirsForLib, java.base, java

2) OpenJ9:
https://github.com/ChengJin01/openj9/commit/2d26ff4dc6bfe8f391fdba9fd7f86af0e5ccda19

e.g. 
export UCRT_LIB=ucrt (required on VS2017)
export VCRUNTIME_LIB=vcruntime (required on VS2017)
export MINGW64_BIN_PATH= C:\mingw-w64\x86_64-8.1.0-win32-seh-rt_v6-rev0\mingw64\bin\  (a latest version of mingw64 must be installed as the integrated version in cygwin is obsolete)

3) OMR:
https://github.com/ChengJin01/omr/commit/d7b6d0c754f26fd4c147d4a626c22742a0ac9232
Note: configure generated by configure.ac

ChengJin01 on 22 Jun 2018

According to the build.log, jvmtitest.rc was compiled twice by RC as follows:

rc -I. -I../../tests/jvmtitests/include -I../../include -I../../oti -I../../nls -I../../omr/include_core  jvmtitest.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.


../../omr/include_core\omrcfg.h(255) : error RC2018: unknown character '0x40'
../../omr/include_core\omrcfg.h(255) : error RC2142: ellipsis requires three periods
...
rc -I. -I../../tests/jvmtitests/include -I../../include -I../../oti -I../../nls -I../../omr/include_core  jvmtitest.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.

If this is not intentional, there might be duplicated steps in dealing with the RC compilation.

ChengJin01 on 22 Jun 2018

1) The issue with getmacros has been resolved after adding one dependency entry for jvmtitest to /runtime/ddr/module.xml as follows:

    <artifact type="target" name="omrddrgen">
        <include-if condition="spec.flags.module_ddr and spec.flags.opt_useOmrDdr"/>
        <dependencies>
                         ...
            <dependency name="jvmtitest">  <-----------------
                <include-if condition="spec.win_.*"/>
            </dependency>
        </dependencies>

2) After deleting /closed/make/lib/LibCommon.gmk (FindSrcDirsForLib no longer exists at make/lib/LibCommon.gmk since JDK11), the build currently fails when compiling the ddr classes:

...
Compiling 12 files for BUILD_DDR_TOOLS
Creating support/modules_libs/java.base/verify.dll from 2 file(s)
Note: c:\temp\openj9-openjdk-jdk\openj9\debugtools\DDR_VM\src\com\ibm\j9ddr\BytecodeGenerator.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Generating DDR pointer classes
Creating support/modules_libs/java.base/java.dll from 70 file(s)
Creating support/native/java.base/fdlibm.lib from 57 file(s)
....
Compiling 6554 files for BUILD_DDR_CLASSES
c:\temp\openj9-openjdk-jdk\openj9\debugtools\DDR_VM\src\com\ibm\j9ddr\vm29\pointer\generated\PSLIST_HEADERPointer.java:172: 
 error: cannot find symbol
 return getU64Bitfield(PSLIST_HEADER._HeaderX64$Depth_s_, PSLIST_HEADER._HeaderX64$Depth_b_);
               ^
  symbol:   method getU64Bitfield(int,int)
  location: class PSLIST_HEADERPointer
   ...
8 errors
make[3]: *** [/cygdrive/c/temp/openj9-openjdk-jdk/closed/make/DDR-jar.gmk:50: 
/cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/support/ddr/classes/_the.BUILD_DDR_CLASSES_batch] Error 1
make[2]: *** [/cygdrive/c/temp/openj9-openjdk-jdk/closed/make/Main.gmk:48: openj9.dtfj-ddr-jar] Error 2
make[2]: *** Waiting for unfinished jobs....
LINK : fatal error LNK1181: cannot open input file 'jvm.lib'  <---------- already generated in vm/lib
make[3]: *** [CoreLibraries.gmk:106: /cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/support/modules_libs/java.base/verify.dll] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2

It looks like the jobs of both building ddr classes and creating .dll files were executed in parallel, which might have something to do with this compilation error.

ChengJin01 on 6 Jul 2018

I discussed the interference of getmacros with compilation steps with @mikezhang1234567890 who will be investigating adjustments to the makefiles to avoid this problem.

The problem related to PSLIST_HEADER can be avoided by adding that type to runtime/ddr/blacklist. I have a branch [1] which expands bitfield support so blacklisting that type should be temporary.

[1] https://github.com/keithc-ca/openj9/tree/ddr-bitfields

keithc-ca on 6 Jul 2018

The suggestion above works to bypass the undefined type PSLIST_HEADER and the compilation stops at creating verify.dll:

...
Creating support/modules_libs/openj9.dtfj/ddr/j9ddr.jar
LINK : fatal error LNK1181: cannot open input file 'jvm.lib' <--------------
make[3]: *** [CoreLibraries.gmk:106: /cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/support/modules_libs/java.base/verify.dll] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2

ERROR: Build failed for target 'all' in configuration 'windows-x86_64-normal-server-release' (exit code 2)

=== Output from failing command(s) repeated here ===
* For target support_native_java.base_libverify_BUILD_LIBVERIFY_link:
LINK : fatal error LNK1181: cannot open input file 'jvm.lib'

Looking at how verify.dll is created at make/lib/CoreLibraries.gmk:

$(eval $(call SetupJdkLibrary, BUILD_LIBVERIFY, \
    NAME := verify, \
    OPTIMIZATION := $(LIBVERIFY_OPTIMIZATION), \
    CFLAGS := $(CFLAGS_JDKLIB), \
    DISABLED_WARNINGS_gcc := implicit-fallthrough, \
    DISABLED_WARNINGS_microsoft := 4244 4267, \
    LDFLAGS := $(LDFLAGS_JDKLIB) \
        $(call SET_SHARED_LIBRARY_ORIGIN), \
    LIBS_unix := -ljvm, \
    LIBS_windows := jvm.lib, \ <---------- jvm.lib is required on Windows
))

Given that jvm.lib was already created at..\build\windows-x86_64-normal-server-release\vm\lib,
It is likely that the compilation fails to locate the path to jvm.lib.

Will check against the compilation on JDK10/OpenJ9 to see how it deals with the issue (e.g. the setting of LDFLAGS_JDKLIB and JAVA_BASE_LDFLAGS).

ChengJin01 on 6 Jul 2018

After fixing the issue with jvm.lib by adding vm/lib to the libpath on Windows, I encountered an issue with unresolved external symbol with JVM_BeforeHalt (only supported since JDK11)

Creating support/modules_libs/openj9.dtfj/ddr/j9ddr.jar
Shutdown.obj : error LNK2019: unresolved external symbol JVM_BeforeHalt referenced in function Java_java_lang_Shutdown_beforeHalt
c:/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/support/modules_libs/java.base/java.dll :
 fatal error LNK1120: 1 unresolved externals
make[3]: *** [CoreLibraries.gmk:130: /cygdrive/c/temp/openj9-openjdk-jdk/build/windows-x86_64-normal-server-release/support/modules_libs/java.base/java.dll] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [make/Main.gmk:215: java.base-libs] Error 2

Given that JVM_BeforeHalt is supported since JDK11, need to check whether it failed to locate the related .lib file or something else missing in code.

ChengJin01 on 10 Jul 2018

With my changes on the latest openj9-openjdk-jdk11, it also shows the same issue with JVM_AreNestMates:

* For target support_native_java.base_libjava_BUILD_LIBJAVA_link:
   Creating library c:/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/support/native/java.base/libjava/java.lib and object c:/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/support/native/java.base/libjava/java.exp
Reflection.obj : error LNK2019: unresolved external symbol JVM_AreNestMates referenced in function Java_jdk_internal_reflect_Reflection_areNestMates <------------
Shutdown.obj : error LNK2019: unresolved external symbol JVM_BeforeHalt referenced in function Java_java_lang_Shutdown_beforeHalt
c:/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/support/modules_libs/java.base/java.dll : fatal error LNK1120: 2 unresolved externals

ChengJin01 on 11 Jul 2018

Both of those symbols are there in runtime/j9vm/java11vmi.c and runtime/redirector/forwarders.m4

Are you linking to the wrong version of jvm.dll somehow?

pshipton on 11 Jul 2018

i.e. runtime/j9vm_jdk11/module.xml creates j9vm_jdk11/jvm.dll and runtime/redirector/module.xml creates jvm_jdk11.dll. Both of these are copied (and jvm_jdk11.dll renamed to jvm.dll) into the correct places when building jdk11.

pshipton on 11 Jul 2018

it looks like the setting in make/lib/CoreLibraries.gmk sticks to jvm.lib. It failed to resolve JVM_AreNestMates & JVM_BeforeHalt because they were missing in jvm.lib.

$(eval $(call SetupJdkLibrary, BUILD_LIBJAVA, \
    NAME := java, \
    OPTIMIZATION := HIGH, \
    CFLAGS := $(CFLAGS_JDKLIB) \
        $(LIBJAVA_CFLAGS), \
    System.c_CFLAGS := $(VERSION_CFLAGS), \
    jdk_util.c_CFLAGS := $(VERSION_CFLAGS), \
    EXTRA_HEADER_DIRS := libfdlibm, \
    WARNINGS_AS_ERRORS_xlc := false, \
    DISABLED_WARNINGS_gcc := unused-result, \
    DISABLED_WARNINGS_solstudio := E_STATEMENT_NOT_REACHED, \
    LDFLAGS := $(LDFLAGS_JDKLIB) \
        $(call SET_SHARED_LIBRARY_ORIGIN), \
   ...
    LIBS_windows := jvm.lib  <--------------------

I am wondering whether jvm.lib must be renamed from vm/j9vm_jdk11/jdk11_jvm.lib and copied to ./vm/lib. If so, then there must be something wrong with the copy operation.

ChengJin01 on 11 Jul 2018

Seems we aren't copying the jvm.lib file (but should be), only the jvm.dll files. i.e. in OpenJ9.gmk

    j9vm_jdk11/$(LIBRARY_PREFIX)jvm$(SHARED_LIBRARY_SUFFIX) \

OPENJ9_REDIRECTOR := redirector/$(LIBRARY_PREFIX)jvm_jdk11$(SHARED_LIBRARY_SUFFIX)

pshipton on 11 Jul 2018

Because jdk10 builds fine with VS2013, I wouldn't expect changes to how jvm.lib is handled in jdk11 with VS2017.

keithc-ca on 11 Jul 2018

These natives were introduced recently since JDK11:
JVM_BeforeHalt
JVM_GetNestHost
JVM_GetNestMembers
JVM_AreNestMates

That means we need to copy the corresponding static library to vm/lib in such case.

ChengJin01 on 11 Jul 2018

Because jdk10 builds fine

I don't think there were any new APIs added between Java 8 and Java 10, only parameter changes to existing APIs.

pshipton on 11 Jul 2018

I think the time has come to collapse all source versions of the redirectors to one that yields the right content for the version of Java being built. Then there will only be one jvm.dll in a given build.

keithc-ca on 11 Jul 2018

👍2

I tried to modify the script at closed/OpenJ9.gmk by adding the following code to renaming/copying redirector_jvm_jdk11.lib & .exp to vm/lib

ifeq (windows,$(OPENJDK_TARGET_OS))
    @$(CP) -p $(OUTPUTDIR)/vm/redirector/redirector_jvm_jdk11$(STATIC_LIBRARY_SUFFIX) $(OUTPUTDIR)/vm/lib/jvm$(STATIC_LIBRARY_SUFFIX)
    @$(CP) -p $(OUTPUTDIR)/vm/redirector/redirector_jvm_jdk11.exp $(OUTPUTDIR)/vm/lib/jvm.exp
endif

The issue with resolving JVM_AreNestMates & JVM_BeforeHalt got fixed but it ended up with the another loading failure as follows:

Compiling 4 files for BUILD_JIGSAW_TOOLS
<error: unable to load java (JVMPORT015E Unable to resolve shared library references - a prerequisite shared library may be missing)>
make[3]: *** [ExplodedImageOptimize.gmk:41: /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/jdk/_packages_attribute.done] Error 1
make[2]: *** [make/Main.gmk:347: exploded-image-optimize] Error 2

make/ExplodedImageOptimize.gmk
$(PACKAGES_ATTRIBUTE_TARGET): $(ALL_MODULEINFO_CLASSES) $(BUILD_JIGSAW_CLASSES)
    $(call LogInfo, Optimizing the exploded image)
    $(TOOL_ADD_PACKAGES_ATTRIBUTE) $(JDK_OUTPUTDIR)  <-------------
    $(TOUCH) $@

TOOL_ADD_PACKAGES_ATTRIBUTE := $(BUILD_JAVA) $(JAVA_FLAGS_SMALL) \
    -cp $(TOOLS_CLASSES_DIR) \
    --add-exports java.base/jdk.internal.module=ALL-UNNAMED \
    build.tools.jigsaw.AddPackagesAttribute

Running "jdk/bin/java version" also ended up with the same failure:

Administrator@JCHWINVM21 /cygdrive/c/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -version
<error: unable to load java (JVMPORT015E Unable to resolve shared library references - a prerequisite shared library may be missing)>

If the copying steps for jvm.lib are correct, then it is likely the failure has something to do with the generated .dll files (e.g. jvm.dll or others)

ChengJin01 on 12 Jul 2018

Seems before trying to get VS2017 working we should ensure a build with VS2013 works.

pshipton on 12 Jul 2018

Also tried copying j9vm_jdk11/jdk11_jvm.lib & .exp to vm/lib/jvm.lib & .exp and an exception occurred when running "java -version":

Compiling 4 files for BUILD_JIGSAW_TOOLS
Exception in thread "main" java/lang/IncompatibleClassChangeError: java/lang/ThreadLocal$ThreadLocalMap.set(Ljava/lang/ThreadLocal;Ljava/lang/Object;)V
        at java/lang/ThreadLocal.set (java.base@9/ThreadLocal.java:222)
        at java/lang/StringCoding.set (java.base@9/StringCoding.java:83)
        at java/lang/StringCoding.encode (java.base@9/StringCoding.java:500)
        at java/lang/System.afterClinitInitialization (java.base@9/System.java:157)
        at java/lang/Thread.initialize (java.base@9/Thread.java:371)
        at java/lang/Thread.<init> (java.base@9/Thread.java:153)
make[3]: *** [ExplodedImageOptimize.gmk:41: /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/jdk/_packages_attribute.done] Error 1
make[2]: *** [make/Main.gmk:347: exploded-image-optimize] Error 2

Administrator@JCHTORWIN101 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -version
Exception in thread "main" java/lang/IncompatibleClassChangeError: java/lang/ThreadLocal$ThreadLocalMap.set(Ljava/lang/ThreadLocal;Ljava/lang/Object;)V
        at java/lang/ThreadLocal.set (java.base@9/ThreadLocal.java:222)
        at java/lang/StringCoding.set (java.base@9/StringCoding.java:83)
        at java/lang/StringCoding.encode (java.base@9/StringCoding.java:500)
        at java/lang/System.afterClinitInitialization (java.base@9/System.java:157)
        at java/lang/Thread.initialize (java.base@9/Thread.java:371)
        at java/lang/Thread.<init> (java.base@9/Thread.java:153)

From the result, it suggests that copying j9vm_jdk11/jdk11_jvm.lib & .exp is correct to some extent.

ChengJin01 on 13 Jul 2018

Seems before trying to get VS2017 working we should ensure a build with VS2013 works.

I used to comment out the code of JVM_BeforeHalt in Shutdown.c on an older version of openj9-openjdk-jdk (jdk11 without any code of NestMates) and It passed in compilation and works in running java -version

Administrator@JCHWINVM21 /cygdrive/c/temp/windows-x86_64-normal-server-release_VS2017_OK_without_JVM_BeforeHalt/windows-x86_64-normal-server-release
$ jdk/bin/java  -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180710_000000 (JIT enabled, AOT enabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

So the problem should have nothing to do with VS2017.

ChengJin01 on 13 Jul 2018

The IncompatibleClassChangeError should be resolved by https://github.com/ibmruntimes/openj9-openjdk-jdk11/pull/3 and https://github.com/eclipse/openj9/pull/2374.

keithc-ca on 16 Jul 2018

With the latest changes above (ibmruntimes/openj9-openjdk-jdk11#3 and #2374), the compilation ended up with a module related exception after copying/rename j9vm_jdk11/jdk11_jvm.lib & .exp to vm/lib:

Compiling 4 files for BUILD_JIGSAW_TOOLS
java.lang.module.FindException: Error reading module: c:\temp\openj9-openjdk-jdk11\build\windows-x86_64-normal-server-release\jdk\modules\java.base
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:349)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)
        at jdk.internal.module.ModulePath.find(java.base@9/ModulePath.java:153)
        at jdk.internal.module.SystemModuleFinders$1.lambda$find$0(java.base@9/SystemModuleFinders.java:215)
        at jdk.internal.module.SystemModuleFinders$1$$Lambda$1.000000000FD2CAE0.run(java.base@9/Unknown Source)
        at java.security.AccessController.doPrivileged(java.base@9/AccessController.java:640)
        at jdk.internal.module.SystemModuleFinders$1.find(java.base@9/SystemModuleFinders.java:216)
        at jdk.internal.module.ModuleBootstrap.boot(java.base@9/ModuleBootstrap.java:211)
        at java.lang.ClassLoader.initializeClassLoaders(java.base@9/ClassLoader.java:217)
        at java.lang.Thread.initialize(java.base@9/Thread.java:422)
        at java.lang.Thread.<init>(java.base@9/Thread.java:153)
Caused by: java.lang.module.InvalidModuleDescriptorException: called wrong accept method
        at jdk.internal.module.ModuleInfo.invalidModuleDescriptor(java.base@9/ModuleInfo.java:1092)
        at jdk.internal.module.ModuleInfo.read(java.base@9/ModuleInfo.java:134)
        at jdk.internal.module.ModulePath.readExplodedModule(java.base@9/ModulePath.java:688)
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:319)
        ... 12 more
make[3]: *** [ExplodedImageOptimize.gmk:41: /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/jdk/_packages_attribute.done] Error 1

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -version
java.lang.module.FindException: Error reading module: C:\temp\openj9-openjdk-jdk11\build\windows-x86_64-normal-server-release\jdk\modules\java.base
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:349)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)
        at jdk.internal.module.ModulePath.find(java.base@9/ModulePath.java:153)
        at jdk.internal.module.SystemModuleFinders$1.lambda$find$0(java.base@9/SystemModuleFinders.java:215)
        at jdk.internal.module.SystemModuleFinders$1$$Lambda$1.00000000107B0B90.run(java.base@9/Unknown Source)
        at java.security.AccessController.doPrivileged(java.base@9/AccessController.java:640)
        at jdk.internal.module.SystemModuleFinders$1.find(java.base@9/SystemModuleFinders.java:216)
        at jdk.internal.module.ModuleBootstrap.boot(java.base@9/ModuleBootstrap.java:211)
        at java.lang.ClassLoader.initializeClassLoaders(java.base@9/ClassLoader.java:217)
        at java.lang.Thread.initialize(java.base@9/Thread.java:422)
        at java.lang.Thread.<init>(java.base@9/Thread.java:153)
Caused by: java.lang.module.InvalidModuleDescriptorException: called wrong accept method
        at jdk.internal.module.ModuleInfo.invalidModuleDescriptor(java.base@9/ModuleInfo.java:1092)
        at jdk.internal.module.ModuleInfo.read(java.base@9/ModuleInfo.java:134)
        at jdk.internal.module.ModulePath.readExplodedModule(java.base@9/ModulePath.java:688)
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:319)
        ... 12 more

If the merged fixes are correct, then the problem might be related to the module setting at java.base (e.g. src/java.base/share/classes/module-info.java)

ChengJin01 on 17 Jul 2018

The detailed backtrace in java is as follows:

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -version
java.lang.NullPointerException
        at java.lang.String.getBytes(java.base@9/String.java)
       ...
        at java.util.stream.ReferencePipeline.collect(java.base@9/ReferencePipeline.java:578)
        at jdk.internal.module.ModulePath.explodedPackages(java.base@9/ModulePath.java:672)
        at jdk.internal.module.ModulePath.lambda$readExplodedModule$9(java.base@9/ModulePath.java:690)
        at jdk.internal.module.ModulePath$$Lambda$2.00000000108A4450.get(java.base@9/Unknown Source)
        at jdk.internal.module.ModuleInfo.doRead(java.base@9/ModuleInfo.java:306) <------------------
        at jdk.internal.module.ModuleInfo.read(java.base@9/ModuleInfo.java:132)
        at jdk.internal.module.ModulePath.readExplodedModule(java.base@9/ModulePath.java:689)
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:319)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)
        at jdk.internal.module.ModulePath.find(java.base@9/ModulePath.java:153)
        at jdk.internal.module.SystemModuleFinders$1.lambda$find$0(java.base@9/SystemModuleFinders.java:215)
        at jdk.internal.module.SystemModuleFinders$1$$Lambda$1.0000000010C90B90.run(java.base@9/Unknown Source)
        at java.security.AccessController.doPrivileged(java.base@9/AccessController.java:640)
        at jdk.internal.module.SystemModuleFinders$1.find(java.base@9/SystemModuleFinders.java:216)
        at jdk.internal.module.ModuleBootstrap.boot(java.base@9/ModuleBootstrap.java:211)
        at java.lang.ClassLoader.initializeClassLoaders(java.base@9/ClassLoader.java:217)
        at java.lang.Thread.initialize(java.base@9/Thread.java:422)
        at java.lang.Thread.<init>(java.base@9/Thread.java:153)

Looking at the code of ModuleInfo.doRead() in src/java.base/share/classes/jdk/internal/module/ModuleInfo.java

    private Attributes doRead(DataInput in) throws IOException {

       ...
        int attributes_count = in.readUnsignedShort();

        // the names of the attributes found in the class file
        Set<String> attributes = new HashSet<>();

        Builder builder = null;
        Set<String> allPackages = null;
        String mainClass = null;
        ModuleTarget moduleTarget = null;
        ModuleHashes moduelHashes = null;
        ModuleResolution moduleResolution = null;

        for (int i = 0; i < attributes_count ; i++) {
            int name_index = in.readUnsignedShort();
            String attribute_name = cpool.getUtf8(name_index);
            int length = in.readInt();

            boolean added = attributes.add(attribute_name);
            if (!added && isAttributeAtMostOnce(attribute_name)) {
                throw invalidModuleDescriptor("More than one "
                                              + attribute_name + " attribute");
            }

            switch (attribute_name) { <--------- not MODULE_PACKAGES ?

                case MODULE :
                    builder = readModuleAttribute(in, cpool, major_version);
                    break;

                case MODULE_PACKAGES :
                    allPackages = readModulePackagesAttribute(in, cpool); <--- or return null
                    break;
               ...

            }
        }
      ...
        // If the ModulePackages attribute is not present then the packageFinder
        // is used to find the set of packages
        boolean usedPackageFinder = false;
        if (allPackages == null && packageFinder != null) { <------- allPackages is null
            try {
                allPackages = packageFinder.get(); <------ exception occurred from inside
            } catch (UncheckedIOException x) {
                throw x.getCause();
            }

    private Set<String> readModulePackagesAttribute(DataInput in, ConstantPool cpool)
        throws IOException
    {
        int package_count = in.readUnsignedShort();
        Set<String> packages = new HashSet<>(package_count);
        for (int i=0; i<package_count; i++) {
            int index = in.readUnsignedShort();
            String pn = cpool.getPackageName(index); <--------- extract package name from constant pool
            boolean added = packages.add(pn);
            if (!added) {
                throw invalidModuleDescriptor("Package " + pn + " in ModulePackages"
                                              + "attribute more than once");
            }
        }
        return packages; <----- returns a set of package names
    }

Looking at src/java.base/share/classes/module-info.java (packages exist in there)

module java.base {

    exports java.io;
    exports java.lang;
    exports java.lang.annotation;
    exports java.lang.invoke;
    exports java.lang.module;
    exports java.lang.ref;
    exports java.lang.reflect;
    exports java.math;
    exports java.net;
    exports java.net.spi;
...

So it seems the failure to parse package names from java.base/module-info.class triggered the exception. Given that the exposed packages exist in java.base, I need to figure out whether
attribute_name in ModuleInfo.doRead() is set to MODULE_PACKAGES or there is any issue with constant pool or something else.

ChengJin01 on 18 Jul 2018

1) I didn't spot anything abnormal with the generated module-info.class at java.base in terms of binary format as well as the original java file.

2) The exceptions above (FindException, etc) seem to be a red herring because the compiled build failed to initialize the library jclse11_29.dll at stage 14 (JCL_INITIALIZED) with JIT off as follows:

Compiling 4 files for BUILD_JIGSAW_TOOLS
JVMJ9VM015W Initialization error for library jclse11_29(14): JVMJ9VM009E J9VMDllMain failed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
make[3]: *** [ExplodedImageOptimize.gmk:41: /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/jdk/_packages_attribute.done] Error 1
make[2]: *** [make/Main.gmk:347: exploded-image-optimize] Error 2


Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java  -Xint -version
JVMJ9VM015W Initialization error for library jclse11_29(14): JVMJ9VM009E J9VMDllMain failed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

If so, it is likely jclse11_29.dll was not generated correctly during compilation or there are still problems with the corresponding config/setting for the library generation.

ChengJin01 on 19 Jul 2018

Investigation shows the problem with jclse11_29 came from the code in J9SigQuitStartup as follows:

jcl/common/sigquit.c
J9SigQuitStartup(J9JavaVM * vm)
{
    PORT_ACCESS_FROM_JAVAVM(vm);

    Trc_JCL_J9SigQuitStartup_Entry();

    if (vm->sigFlags & J9_SIG_NO_SIG_QUIT) {
        /* Set if -Xrs command-line option */
        Trc_JCL_J9SigQuitStartup_Disabled();
        return 0;
    }

    if (j9sig_set_async_signal_handler(sigQuitWrapper, vm, J9PORT_SIG_FLAG_SIGQUIT)) {
        Trc_JCL_J9SigQuitStartup_Failure();
        return JNI_ERR;  <------------- failure to set up the SigQuit handler
    }

    vm->J9SigQuitShutdown = J9SigQuitShutdown;

    Trc_JCL_J9SigQuitStartup_Exit();

    return 0;
}

The problem with Initialization disappear if disabling SigQuit with -Xrs (JIT off)

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -Xrs -Xint -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build Fix_issues_Win_JDK11-0b1cd35e, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180719_000000 (JIT disabled, AOT disabled)
OpenJ9   - 0b1cd35e
OMR      - c402a576
JCL      - 7b9095d1b6 based on jdk-11+21)

How, the issue with module-info.class still exist with JIT on:

$ jdk/bin/java   -Xrs -version
java.lang.module.FindException: Error reading module: C:\temp\openj9-openjdk-jdk11\build\windows-x86_64-normal-server-release\jdk\modules\java.base
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:349)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)
        at jdk.internal.module.ModulePath.find(java.base@9/ModulePath.java:153)
        at jdk.internal.module.SystemModuleFinders$1.lambda$find$0(java.base@9/SystemModuleFinders.java:215)
        at jdk.internal.module.SystemModuleFinders$1$$Lambda$1.00000000103B9BA0.run(java.base@9/Unknown Source)
        at java.security.AccessController.doPrivileged(java.base@9/AccessController.java:640)
        at jdk.internal.module.SystemModuleFinders$1.find(java.base@9/SystemModuleFinders.java:216)
        at jdk.internal.module.ModuleBootstrap.boot(java.base@9/ModuleBootstrap.java:211)
        at java.lang.ClassLoader.initializeClassLoaders(java.base@9/ClassLoader.java:217)
        at java.lang.Thread.initialize(java.base@9/Thread.java:422)
        at java.lang.Thread.<init>(java.base@9/Thread.java:153)
Caused by: java.lang.module.InvalidModuleDescriptorException: called wrong accept method
        at jdk.internal.module.ModuleInfo.invalidModuleDescriptor(java.base@9/ModuleInfo.java:1092)
        at jdk.internal.module.ModuleInfo.read(java.base@9/ModuleInfo.java:134)
        at jdk.internal.module.ModulePath.readExplodedModule(java.base@9/ModulePath.java:688)
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:319)
        ... 12 more

So it is hard to determine whether they came from the same root cause or they are totally different issues.

ChengJin01 on 20 Jul 2018

I think the root cause for unresolved external symbol to JVM_BeforeHalt/JVM_AreNestMates is that these natives not exported via j9vm/module.xml. So I made some changes as follows:

    <exports group="all">
        <export name="JNI_CreateJavaVM" />
        <export name="JNI_GetCreatedJavaVMs" />
        <export name="JNI_GetDefaultJavaVMInitArgs" />
        <export name="_JVM_GetCallerClass@8" />
        <export name="JVM_BeforeHalt" />  <----------- added from this line
        <export name="JVM_GetNestHost" />
        <export name="JVM_GetNestMembers" />
        <export name="JVM_AreNestMates" />
    </exports>

        <flags>
            <flag name="J9VM_JAVA9_BUILD" value="148"/>
            <flag name="J9VM_JCL_SE11"/>  <------------------- specify jclse11
        </flags>

The compilation ended up with the same result as copying/renaming j9vm_jdk11/jdk11_jvm.lib & .exp to vm/lib, which means copying/renaming j9vm_jdk11/jdk11_jvm.lib was incorrect or at least unnecessary.

$ jdk/bin/java -Xint -version
JVMJ9VM015W Initialization error for library jclse11_29(14): JVMJ9VM009E J9VMDllMain failed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ jdk/bin/java  -Xrs -Xint -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build Fix_issues_Win_JDK11-0b1cd35e, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180720_000000 (JIT disabled, AOT disabled)
OpenJ9   - 0b1cd35e
OMR      - c402a576
JCL      - 7b9095d1b6 based on jdk-11+21)

If so, I need to double-check the generation of jclse11_29.dll as well as all related module.xml to see whether there is anything else should be fixed.

ChengJin01 on 21 Jul 2018

I tried two steps to narrow down the scope:
1) compiled an older version openJDK11 (only support JVM_BeforeHalt) and openJ9 (including the setting and empty interfaces of JVM_BeforeHalt, JVM_AreNestMates, etc) and it finished without any error:

$ jdk/bin/java  -Xint  -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v1openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180721_000000 (JIT disabled, AOT disabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

$ jdk/bin/java  -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v1openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180721_000000 (JIT enabled, AOT enabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

2) compiled the same version of openJDK11(only support JVM_BeforeHalt) and the latest version of openJ9 (support all JDK11 natives, including JVM_BeforeHalt, JVM_AreNestMates, etc) and it ended up with same failure as the latest version of openJDK11:

Compiling 4 files for BUILD_JIGSAW_TOOLS
java.lang.NullPointerException
        at java.util.stream.ReduceOps$3ReducingSink.begin(java.base@9/ReduceOps.java:164)
        at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining(java.base@9/Streams.java:432)
        at java.util.stream.ReferencePipeline$Head.forEach(java.base@9/ReferencePipeline.java:658)
        at java.util.stream.ReferencePipeline$7$1.accept(java.base@9/ReferencePipeline.java:274)
        at java.util.stream.ReferencePipeline$3$1.accept(java.base@9/ReferencePipeline.java:195)
        at java.util.stream.ReferencePipeline$3$1.accept(java.base@9/ReferencePipeline.java:195)
        at java.util.stream.ReferencePipeline$3$1.accept(java.base@9/ReferencePipeline.java:195)
...

Administrator@JCHWINVM21 /cygdrive/c/temp/v1_1_openj9-openjdk-jdk/build/windows-x86_64-normal-server-release
$ jdk/bin/java   -version
java.lang.module.FindException: Error reading module: C:\temp\v1_1_openj9-openjdk-jdk\build\windows-x86_64-normal-server-release\jdk\modules\java.base
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:349)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)

Administrator@JCHWINVM21 /cygdrive/c/temp/v1_1_openj9-openjdk-jdk/build/windows-x86_64-normal-server-release
$ jdk/bin/java  -Xint  -version
JVMJ9VM015W Initialization error for library jclse11_29(14): JVMJ9VM009E J9VMDllMain failed
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Administrator@JCHWINVM21 /cygdrive/c/temp/v1_1_openj9-openjdk-jdk/build/windows-x86_64-normal-server-release
$ jdk/bin/java  -Xrs  -Xint  -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v11openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_Win_JDK11-0b1cd35e, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180722_000000 (JIT disabled, AOT disabled)
OpenJ9   - 0b1cd35e
OMR      - c402a576
JCL      - 313973a59a based on jdk-11+17)

So the investigation above indicates:
(1) the problem has nothing to with the latest version of openJDK11
(2) the problem came from the recent changes for JDK11 in openJ9, especially the changes with nestMates.

ChengJin01 on 22 Jul 2018

1) With the same old version JDK11 (only support JVM_BeforeHalt) , I manually merged the changes at https://github.com/eclipse/openj9/pull/2270 (turn on the changes for nestMates on OpenJ9 ) to the older version of OpenJ9 ( (including the setting and empty interfaces of JVM_BeforeHalt, JVM_AreNestMates, etc) and it ended up with pretty much the same compilation failures as the result above at 2).

$ jdk/bin/java   -Xint -version  (worked but ran very slowly (over 30 secs))
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v12openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180723_000000 (JIT disabled, AOT disabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

$ jdk/bin/java    -version
java.lang.module.FindException: Error reading module: C:\temp\v1_2_openj9-openjdk-jdk\build\windows-x86_64-normal-server-release\jdk\modules\java.base
        at jdk.internal.module.ModulePath.readModule(java.base@9/ModulePath.java:349)
        at jdk.internal.module.ModulePath.scanDirectory(java.base@9/ModulePath.java:283)
        at jdk.internal.module.ModulePath.scan(java.base@9/ModulePath.java:231)
        at jdk.internal.module.ModulePath.scanNextEntry(java.base@9/ModulePath.java:189)
        at jdk.internal.module.ModulePath.find(java.base@9/ModulePath.java:153)
        at jdk.internal.module.SystemModuleFinders$1.lambda$find$0(java.base@9/SystemModuleFinders.java:214)
        at jdk.internal.module.SystemModuleFinders$1$$Lambda$1.000000000FAFEF00.run(java.base@9/Unknown Source)
        at java.security.AccessController.doPrivileged(java.base@9/AccessController.java:640)
        at jdk.internal.module.SystemModuleFinders$1.find(java.base@9/SystemModuleFinders.java:215)
        at jdk.internal.module.ModuleBootstrap.boot(java.base@9/ModuleBootstrap.java:211)
        at java.lang.ClassLoader.initializeClassLoaders(java.base@9/ClassLoader.java:217)
        at java.lang.Thread.initialize(java.base@9/Thread.java:422)
        at java.lang.Thread.<init>(java.base@9/Thread.java:153)

2) After removing J9VM_OPT_VALHALLA_NESTMATES in j9cfg.h.in and j9cfg.h.ftl, all problems above disappeared and the compilation finished without any error.

$ jdk/bin/java   -version  (ran vary fast (within 3 secs))
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v12openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180723_000000 (JIT enabled, AOT enabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

$ jdk/bin/java  -Xint  -version (ran vary fast (within 3 secs))
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.v12openj9-openjdk-jdk)
Eclipse OpenJ9 VM (build Fix_issues_JDK11_Windows-2d26ff4d, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180723_000000 (JIT disabled, AOT disabled)
OpenJ9   - 2d26ff4d
OMR      - d7b6d0c7
JCL      - 313973a59a based on jdk-11+17)

Given that turning on J9VM_OPT_VALHALLA_NESTMATES enables all code changes of nestMates, I suspect there might be code issues in the existing implementation of nestMates. If so, there is no way to fix them in our script/setting from the compilation perspective (This is the only issue left here). I will double-check all my changes so far in jdk11/OpeJ9/omr and submit them for review soon.

FYI: @tajila.

ChengJin01 on 24 Jul 2018

The issues with nestmates should go away once https://github.com/eclipse/openj9/pull/2459 is merged.

keithc-ca on 24 Jul 2018

After manually merging the changes at https://github.com/eclipse/openj9/pull/2459, all problems with nestMates were fixed and the compilation passed without error:

...
Compiling 4 files for BUILD_JIGSAW_TOOLS
Creating images/jmods/java.datatransfer.jmod
Creating images/jmods/java.compiler.jmod
Creating images/jmods/java.instrument.jmod
Creating images/jmods/java.desktop.jmod
Creating images/jmods/java.logging.jmod
...
Creating support/demos/image/jfc/TableExample/TableExample.jar
Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar
Creating jdk image
Stopping sjavac server
Finished building target 'all' in configuration 'windows-x86_64-normal-server-release'


Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/images
$ jdk/bin/java    -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build Fix_issues_Win_JDK11-11410ac2, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180724_000000 (JIT enabled, AOT enabled)
OpenJ9   - 11410ac2
OMR      - e2e4b67c
JCL      - a786f96b13 based on jdk-11+21)


Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/images
$ jdk/bin/java   -Xint    -version
openjdk version "11-internal" 2018-09-25
OpenJDK Runtime Environment (build 11-internal+0-adhoc.Administrator.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build Fix_issues_Win_JDK11-11410ac2, JRE 11 Windows 7 amd64-64-Bit Compressed References 20180724_000000 (JIT disabled, AOT disabled)
OpenJ9   - 11410ac2
OMR      - e2e4b67c
JCL      - a786f96b13 based on jdk-11+21)

Given all issues are fixed in compilation, I will set up to run sanity test to verify its basic functionalities.

ChengJin01 on 24 Jul 2018

🎉1

A test failure with UnsatisfiedLinkError is detected during the sanity test as follows:

Problem opening JNI library
java.lang.UnsatisfiedLinkError: j9ben (Not found in java.library.path)
        at java.lang.ClassLoader.loadLibraryWithPath(java.base@11-internal/ClassLoader.java:1678)
...
or 
Testing no deadlocks...No natives for j9vm.test.thread tests
Exception in thread "main" java.lang.UnsatisfiedLinkError: j9vm/test/thread/NativeHelpers.findDeadlockedThreads()[Ljava/lang/Thread;
        at j9vm.test.thread.FindDeadlockTest.checkDeadlocks(FindDeadlockTest.java:177)
        at j9vm.test.thread.FindDeadlockTest.testNoDeadlocks(FindDeadlockTest.java:301)
        at j9vm.test.thread.FindDeadlockTest.runTests(FindDeadlockTest.java:204)
        at j9vm.test.thread.FindDeadlockTest.main(FindDeadlockTest.java:29)
...

Look at the test code:

    static boolean checkDeadlocks(Thread[] expThreads, Object[] expObjs) {
        boolean ok = true;

        Thread dthreads[] = NativeHelpers.findDeadlockedThreads(); <------
        if (!FindDeadlockTest.matchThreads(dthreads, expThreads)) {
            ok = false;
        }

public class NativeHelpers {
    static {
        try {
            System.loadLibrary("j9ben");  <-------------- missing when loading
        } catch (UnsatisfiedLinkError e) {
            System.out.println("No natives for j9vm.test.thread tests");
        }
    }

Currently I am running tests with .../build/windows-x86_64-normal-server-release/images/jdk/bin

Comparison with the compiled build with openjdk8/open9 shows the j9ben.dll exists in .../build/windows-x86_64-normal-server-release/jdk/bin/compressedrefs but missing in openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/images/jdk/bin/compressedrefs

openj9-openjdk-jdk8/build/windows-x86_64-normal-server-release
$ find . -name j9ben.*
./images/j2re-image/bin/compressedrefs/j9ben.dll
./images/j2sdk-image/jre/bin/compressedrefs/j9ben.dll
./jdk/bin/compressedrefs/j9ben.dll
./vm/j9ben.dll
./vm/j9ben.pdb
./vm/lib/j9ben.exp
./vm/lib/j9ben.lib
./vm/tests/jni/j9ben.def
./vm/tests/jni/j9ben.map
./vm/tests/jni/j9ben.rc
./vm/tests/jni/j9ben.res

openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release
$ find . -name  j9ben.*
./jdk/bin/compressedrefs/j9ben.dll
./vm/j9ben.dll
./vm/j9ben.pdb
./vm/lib/j9ben.exp
./vm/lib/j9ben.lib
./vm/tests/jni/j9ben.def
./vm/tests/jni/j9ben.map
./vm/tests/jni/j9ben.rc
./vm/tests/jni/j9ben.res

Looking at the dll files at jdk/bin/compressedrefs and images/jdk/bin/compressedrefs:

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/jdk/bin/compressedrefs
$ ls
balloon29.dll        j9shr29.dll             jvm.dll
bcuwhite.dll         j9thr29.dll             jvmtitest.dll
bcvwhite.dll         j9thrnumanatives29.dll  management.dll
cuda4j29.dll         j9thrtestnatives29.dll  management_ext.dll
gptest.dll           j9trc29.dll             memorywatcher29.dll
hooktests.dll        j9vm29.dll              migration.dll
j9ben.dll            j9vmchk29.dll           omrsig.dll
j9ddr_misc29.dll     j9vmtest.dll            osmemory29.dll
j9dfix29.dll         j9vrb29.dll             SharedClassesNativeAgent.dll
j9dmp29.dll          j9windbg.dll            softmxtest.dll
j9gc29.dll           j9zlib29.dll            testjvmtiA.dll
j9gcchk29.dll        jclse10_29.dll          testjvmtiB.dll
j9hookable29.dll     jclse11_29.dll          testlibA.dll
j9jextract.dll       jclse7b_29.dll          testlibB.dll
j9jit29.dll          jclse9_29.dll           thrtrace.dll
j9jnichk29.dll       jcoregen29.dll          vmruntimestateagent29.dll
j9jvmti29.dll        jlmagent29.dll          win_6429.dll
j9lazyClassLoad.dll  jniargtests.dll
j9prt29.dll          jsig.dll

Administrator@JCHWINVM21 /cygdrive/c/temp/openj9-openjdk-jdk11/build/windows-x86_64-normal-server-release/images/jdk/bin/compressedrefs
$ ls
cuda4j29.dll      j9jnichk29.dll  j9vm29.dll      jvm.dll
j9dmp29.dll       j9jvmti29.dll   j9vmchk29.dll   management.dll
j9gc29.dll        j9prt29.dll     j9vrb29.dll     management_ext.dll
j9gcchk29.dll     j9shr29.dll     j9zlib29.dll    omrsig.dll
j9hookable29.dll  j9thr29.dll     jclse11_29.dll
j9jit29.dll       j9trc29.dll     jsig.dll

It seems a lot of test related dll files are missing in images/jdk/bin/compressedrefs except j9ben.dll.

@keithc-ca, I suspect the current script in openjdk11 didn't or failed to copy these dll files from /vm to the right place after improving these setting (e.g. OpenJ9.gmk). If so, the issue should be fixed to enable the test execution.

ChengJin01 on 25 Jul 2018

The JDK should have none of those tests DLLs: tests should bring their own DLLs rather than expect the JDK to have them.

keithc-ca on 25 Jul 2018

👍3

We'll have to put the test libraries into images/test I expect. Then PR builds and pipeline builds will have to find them there.

pshipton on 25 Jul 2018

I already finished the sanity test with build/windows-x86_64-normal-server-release/jdk/bin and it shows the compiled build functionally works:

TEST TARGETS SUMMARY
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PASSED test targets:
        cmdLineTester_test_0
        cmdLineTest_J9test_0
        cmdLineTester_GCRegressionTests_2
        cmdLineTester_gcsuballoctests_0
        cmdLineTester_ignoreunrecognizedvmoptions_0
        cmdLineTester_J9securityTests_0
        cmdLineTester_jvmtitests_1
        cmdLineTester_jvmtitests_2
        cmdLineTester_jvmtitests_7
        cmdLineTester_jvmtitests_8
        cmdLineTester_jvmtitests_hcr_4
        cmdLineTester_jvmtitests_hcr_8
        cmdLineTester_jvmtitests_hcr_10
        cmdLineTester_decompilationTests_1
        decompileAtMethodResolve_0
        cmdLineTester_libpathTestRtf_0
        cmdLineTester_libpathTestRtfChild_0
        cmdLineTester_loadLibraryTests_0
        cmdLineTester_loopReduction_0
        cmdLineTester_getPid_0
        cmdLineTester_DataHelperTests_1
        testSCCMLTests1_1
        cmdLineTester_SCHelperCompatibilityTests_win_1
        cmdLineTester_ShareClassesSimpleSanity_1
        cmdLineTester_SCURLHelperTests_90_1
        cmdLineTester_SCURLClassLoaderTests_1
        cmdLineTester_SCURLClassLoaderNPTests_1
        cmdLineTester_XcheckJNI_0
        testXXArgumentTesting_0
        String_CompactStrings_0
        generalSanityTest_0
        regressionFastresolve_mode150_0
        AttachAPISanity_0
        CtorBCVTests_0
        J9VMInternals_Test_0
        JCL_Test_JITHelpers_0
        TestArrayCopy_2
        TestArrayCopy_3
        pthreadDestructor_0
        testReflectInvoke_0
        testInvokeSpecialInsideInterface_0
        reflect_getMethods_0
        NoSuchMethodTests_0
        hanoiTest_0
        memleaksTest_0
        fibTest_0
        testStringInterning_1
        floatSanityTests_0
        floatSanityTests_2
        FileSystem-isAccessUserOnlyTests_0
        Test_Class_0
        TestFlushReflectionCache_0
        TestRefreshGCSpecialClassesCache_NOBCI_0
        stringConcatOptTest_0
        jit_jitt_0
        jit_jitt_1
        jit_jitt_2
        jit_jitt_3
        jit_jar_0
        jit_tr_0
        StringPeepholeTest_0
        jit_vich_0
        JLM_Tests_class_0
        JLM_Tests_class_1
        JLM_Tests_IBMinternal_0
        JLM_Tests_IBMinternal_1
        openj9_jsr292Test_0
        openj9_jsr292Test_JitCount0_0
        SharedCPEntryInvokerTests_0
        SharedCPEntryInvokerTests_1
        UnsafeTests_0
        UnsafeTests_1

FAILED test targets:
        cmdLineTester_callsitedbgddrext_openj9_0
        cmdLineTester_GCRegressionTests_3
        testSCCMLModularity_1
        JCL_Test_0
        JCL_Test_1
        JCL_Test_OutOfMemoryError_0
        JCL_Test_OutOfMemoryError_1
        JCL_TEST_Java-Security_0
        JCL_Test_Package_0
        JLM_Tests_interface_0
        JLM_Tests_interface_1
        J9vmTest_4
        J9vmTest_5

TOTAL: 166   EXECUTED: 85   PASSED: 72   FAILED: 13   SKIPPED: 81

==========

ChengJin01 on 25 Jul 2018

I will prepare all changes I made in compilation for review before addressing the test failure in another issue.

ChengJin01 on 25 Jul 2018

All script/setting changes have been submitted for review:
OpenJDK11: https://github.com/ibmruntimes/openj9-openjdk-jdk11/pull/7
OpenJ9: https://github.com/eclipse/openj9/pull/2483
OMR: https://github.com/eclipse/omr/pull/2798

ChengJin01 on 26 Jul 2018

I don't think this is going to be ready for the 0.10.0 release, deferring.

pshipton on 4 Sep 2018

@pshipton We should be trying to contain this in the 0.10.0 release to match the compiler levels used by OpenJDK.

Is there a critical blocker preventing this from making the 0.10.0 release? If so, let's identify it and try to solve it.

DanHeidinga on 4 Sep 2018

I have been working on https://github.com/eclipse/omr/issues/2885 which would be a prerequisite of DDR support with that compiler.

keithc-ca on 4 Sep 2018

Closing, since Java 11 Windows is now compiling with MSVC 2017.

pshipton on 18 Sep 2018

Openj9: Support for compiling Windows on VS2017

Most helpful comment

All 72 comments

compilation rule for resource files.

include

include

include "j9cfg.h" <----------- (#include "omrcfg.h" in j9cfg.h)

include "j9version.h"

Related issues