RFR(L) : 8199382 : [TESTBUG] Open source VM testbase JDI tests

http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html > 577169 lines changed: 577169 ins; 0 del; 0 mod; Hi all, could you please review the patch which open sources JDI tests from vm testbase? These tests cover different aspects of JDI implementation. As usually w/ VM testbase

Re: Fwd: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6

Looks okay. Thanks, David On 4/05/2018 8:01 AM, gary.ad...@oracle.com wrote: Attached an updated patch for 8202319. Kim or David could you please sponsor the push of the patch. On 4/26/18 6:49 PM, gary.ad...@oracle.com wrote: Adding build-dev and hotspot-runtime-dev aliases.

Re: Fwd: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6

Attached an updated patch for 8202319. Kim or David could you please sponsor the push of the patch. On 4/26/18 6:49 PM, gary.ad...@oracle.com wrote: Adding build-dev and hotspot-runtime-dev aliases. Forwarded Message Subject: RFR: JDK-8202319: Fix compilation warnings in

Re: Windows: problem with msvxxx.dll locations containing spaces

Hello, In my case, VCINSTALLDIR is in short form already. Could you try changing line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? /Erik On 2018-05-03 11:17, Thomas Stüfe wrote: Hi Erik, I see the error on two very different machines. One is my private machine -

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

> On May 3, 2018, at 1:52 PM, B. Blaser wrote: > > Hi, > > On 2 May 2018 at 22:40, Kim Barrett wrote: >>> On May 2, 2018, at 5:10 AM, Michal Vala wrote: >>> >>> >>> >>> On 05/01/2018 07:59 PM, Kim Barrett wrote: > On Apr 27,

Re: Windows: problem with msvxxx.dll locations containing spaces

Hi Erik, I see the error on two very different machines. One is my private machine - windows 7, VS2013 and VS2017 installed. The second one is my corporate Laptop, Windows 10 and only VS2013. In both cases I use a very recent cygwin64 installation. Both cases run in TOOLCHAIN_SETUP_MSVC_DLL

Re: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated

Hi, On 2 May 2018 at 22:40, Kim Barrett wrote: >> On May 2, 2018, at 5:10 AM, Michal Vala wrote: >> >> >> >> On 05/01/2018 07:59 PM, Kim Barrett wrote: On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: Someone to sponsor this

Re: RFR: 8200729: Conditional compilation of GCs

Hi Vladimir, On 2018-05-03 18:56, Vladimir Kozlov wrote: I see that you don't guard Use*GC flags with _ONLY macros. It is hard to figure out from gcConfig.cpp what happened if UseG1GC is specified on command line for VM which does not include it. What happens? Right. The current patch leaves

Re: Windows: problem with msvxxx.dll locations containing spaces

Also, on my windows system, if I try using my local Visual Studio, both MSVC dll's are found in the Visual Studio dir, and the spaces are all cleaned up. I wonder what's different about your setup, Thomas. /Erik On 2018-05-03 10:13, Erik Joelsson wrote: Hello, On 2018-05-03 03:41, Magnus

Re: Windows: problem with msvxxx.dll locations containing spaces

Hello, On 2018-05-03 03:41, Magnus Ihse Bursie wrote: I think the main issue here is that BASIC_FIXUP_PATH should be called for the located msvcr*.dll files. I don't have time to look at it now, but see if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is located. This

Re: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Looks good. /Erik On 2018-05-03 04:33, Severin Gehwolf wrote: Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with:

Re: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

Thank you, Magnus On 5/3/18 1:40 AM, Magnus Ihse Bursie wrote: On 2018-05-03 00:13, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Looks good to me. Just some thinking out loud... The way we handle the

Re: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

Thank you, Stefan Vladimir K On 5/3/18 12:20 AM, Stefan Karlsson wrote: Looks good to me. Thanks for fixing. StefanK On 2018-05-03 00:13, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Stefan K. found several

Re: License and Usage Terms of generated API documentation

On 2018-05-03 13:21, Magnus Ihse Bursie wrote: > A lot of links on the interwebz are pointing to the docs at > docs.oracle.com, and it would probably be quite messy if the same (or > even worse, almost the same) documentation were published both at > docs.oracle.com and java.net. Well, until

Re: RFR: 8200729: Conditional compilation of GCs

On 2018-05-03 15:19, Erik Helin wrote: On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > Hi all, Hi Stefan, thanks for taking on this work, much appreciated! On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > The first patch simply cleans up some INCLUDE_ALL_GCS usages in platform-specific

Re: RFR: 8200729: Conditional compilation of GCs

On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > Hi all, Hi Stefan, thanks for taking on this work, much appreciated! On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > The first patch simply cleans up some INCLUDE_ALL_GCS usages in platform-specific files. Some of these changes are already

Re: Windows: problem with msvxxx.dll locations containing spaces

Thank you Magnus, will do. On Thu, May 3, 2018 at 12:41 PM, Magnus Ihse Bursie wrote: > I think the main issue here is that BASIC_FIXUP_PATH should be called for > the located msvcr*.dll files. I don't have time to look at it now, but see > if you can do a rewrite

Re: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

On 2018-05-03 13:33, Severin Gehwolf wrote: Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,defs" Attempting a

Re: License and Usage Terms of generated API documentation

On Thu, May 3, 2018 at 12:21 PM, Magnus Ihse Bursie wrote: > On 2018-05-02 17:03, Volker Simonis wrote: >> >> Hi, >> >> we currently build OpenJDK and make it available from various sources >> (e.g. GitHub, apt-get server, DockerHub). We also build the API >>

[8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols

Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,defs" Attempting a build of JDK 8 with this fails. This has been

Re: Windows: problem with msvxxx.dll locations containing spaces

I think the main issue here is that BASIC_FIXUP_PATH should be called for the located msvcr*.dll files. I don't have time to look at it now, but see if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is located. This should remove all spaces from the path. /Magnus On

Re: License and Usage Terms of generated API documentation

On 2018-05-02 17:03, Volker Simonis wrote: Hi, we currently build OpenJDK and make it available from various sources (e.g. GitHub, apt-get server, DockerHub). We also build the API documentation (i.e. JavaDoc) and would like to make it available from our project page as well. However the

Re: RFR: 8200729: Conditional compilation of GCs

On 2018-05-03 11:06, Magnus Ihse Bursie wrote: On 2018-05-02 16:37, Stefan Karlsson wrote: Hi all, Please review these patches to allow for conditional compilation of the GCs in HotSpot. Full patch: http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ It's nice to see this cleanup

Re: RFR: 8200729: Conditional compilation of GCs

On 2018-05-02 16:37, Stefan Karlsson wrote: Hi all, Please review these patches to allow for conditional compilation of the GCs in HotSpot. Full patch: http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ It's nice to see this cleanup in build logic! I spotted one issue with the

Re: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

On 2018-05-03 00:13, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Looks good to me. Just some thinking out loud... The way we handle the responsibility split between the makefiles and the hotspot source files is

Re: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT

Looks good to me. Thanks for fixing. StefanK On 2018-05-03 00:13, Vladimir Kozlov wrote: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Stefan K. found several places where #ifdef instead of #if is used for INCLUDE_JVMCI. I also found