Bug 225054 - java/openjdk* : fails to build with clang 6.0 (blocks 571 ports)
Summary: java/openjdk* : fails to build with clang 6.0 (blocks 571 ports)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jung-uk Kim
URL:
Keywords: needs-patch
: 225249 (view as bug list)
Depends on:
Blocks: 224669
  Show dependency treegraph
 
Reported: 2018-01-10 16:09 UTC by Jan Beich
Modified: 2018-02-23 18:16 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (java)


Attachments
blind fix: use "lock" as prefix (3.94 KB, patch)
2018-01-10 16:35 UTC, Jan Beich
no flags Details | Diff
clang 6 fixes for openjdk8 (3.69 KB, patch)
2018-01-13 00:15 UTC, Dimitry Andric
no flags Details | Diff
Fix attempt to reinitialize read-only memory (1.26 KB, patch)
2018-01-18 11:31 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Beich freebsd_committer freebsd_triage 2018-01-10 16:09:47 UTC
FreeBSD -CURRENT plans to update base Clang to 6.0.0 soon. While testing this port failed to build.

In file included from hotspot/src/share/vm/utilities/accessFlags.cpp:26:
In file included from hotspot/src/share/vm/oops/oop.inline.hpp:28:
In file included from hotspot/src/share/vm/gc_implementation/shared/ageTable.hpp:30:
In file included from hotspot/src/share/vm/runtime/perfData.hpp:28:
In file included from hotspot/src/share/vm/memory/allocation.inline.hpp:28:
In file included from hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21: error: unknown token in expression
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    ^
hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:48:24: note: expanded from macro 'LOCK_IF_MP'
#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
                       ^
<inline asm>:1:30: note: instantiated into assembly here
        cmp $0, %esi; je 1f; lock; 1: cmpxchgl %ecx,(%edi)
                                    ^

To reproduce:
$ poudriere jail -cj clang6-amd64 -a amd64 -v projects/clang600-import -m svn+https
$ poudriere bulk -Ctj clang6-amd64 java/openjdk6 java/openjdk7 java/openjdk8

http://package18.nyi.freebsd.org/data/headamd64PR224669-default/2018-01-10_07h00m34s/logs/errors/openjdk6-b44,1.log
http://package18.nyi.freebsd.org/data/headamd64PR224669-default/2018-01-10_07h00m34s/logs/errors/openjdk8-8.152.16_2.log
http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-09_21h45m33s/logs/errors/openjdk6-b44,1.log
http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-09_21h45m33s/logs/errors/openjdk8-8.152.16_2.log
Comment 1 Jan Beich freebsd_committer freebsd_triage 2018-01-10 16:35:50 UTC
Created attachment 189594 [details]
blind fix: use "lock" as prefix

My guess, Clang integrated assembler no longer accepts "lock" as standalone instruction.
Comment 2 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-10 18:47:55 UTC
This patch does not look good.  The previous inline assembly should generate something like this:

	je	.Ltmp0
	lock
.Ltmp0:
	cmpxchgl	%ecx, (%edi)

Assembled:

   4:	0f 84 01 00 00 00    	je     b <test+0xb>
   a:	f0 67 0f b1 0f       	lock addr32 cmpxchg %ecx,(%edi)

Your patch will generate something like this:

	je	.Ltmp0
.Ltmp0:
	lock
	cmpxchgl	%ecx, (%edi)

Assembled:

   4:	0f 84 00 00 00 00    	je     a <test+0xa>
   a:	f0 67 0f b1 0f       	lock addr32 cmpxchg %ecx,(%edi)

As you can see, this patch *always* adds the prefix for cmpxchg.
Comment 3 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-10 18:53:48 UTC
Can you please try something like this?

+-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
++#define LOCK_IF_MP(mp) "cmp $0, " #mp "\nje 1f\nlock\n1: "
Comment 4 Jan Beich freebsd_committer freebsd_triage 2018-01-10 19:32:49 UTC
No joy with \n

In file included from hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21: error: unknown token in expression
  __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                    ^
hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:48:55: note: expanded from macro 'LOCK_IF_MP'
#define LOCK_IF_MP(mp) "cmp $0, " #mp "\nje 1f\nlock\n1: "
                                                      ^
<inline asm>:4:2: note: instantiated into assembly here
1: cmpxchgl %ecx,(%rdi)
 ^

openjdk6 - https://ptpb.pw/6chE
openjdk8 - https://ptpb.pw/CXbx

openjdk7 is also affected by

In file included from hotspot/src/share/vm/precompiled/precompiled.hpp:259:
In file included from hotspot/src/share/vm/opto/addnode.hpp:28:
In file included from hotspot/src/share/vm/opto/node.hpp:30:
In file included from hotspot/src/share/vm/opto/compile.hpp:44:
In file included from hotspot/src/share/vm/trace/tracing.hpp:28:
In file included from ../generated/tracefiles/traceEventClasses.hpp:18:
hotspot/src/share/vm/trace/traceStream.hpp:44:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
    _st.print("%s = "UINT32_FORMAT, label, val);
                     ^
                      
hotspot/src/share/vm/trace/traceStream.hpp:48:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
    _st.print("%s = "UINT32_FORMAT, label, val);
                     ^
                      
hotspot/src/share/vm/trace/traceStream.hpp:52:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
    _st.print("%s = "INT32_FORMAT, label, val);
                     ^
                      
hotspot/src/share/vm/trace/traceStream.hpp:56:22: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
    _st.print("%s = "UINT32_FORMAT, label, val);
                     ^

http://package18.nyi.freebsd.org/data/headi386PR224669-default/2018-01-07_22h53m03s/logs/errors/openjdk-7.151.01,1.log
Comment 5 Jan Beich freebsd_committer freebsd_triage 2018-01-10 19:36:32 UTC
Dimitry, can you find Clang commit that changed integrated assembler in order for us to better understand the rationale?
Comment 6 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-10 19:40:35 UTC
(In reply to Jan Beich from comment #4)

That's bad. :-(

Then, I guess we have no choice but to do something like this:

+-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
++#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; .byte 0xf0; 1: "
Comment 7 Dimitry Andric freebsd_committer freebsd_triage 2018-01-10 19:48:50 UTC
(In reply to Jan Beich from comment #5)
> Dimitry, can you find Clang commit that changed integrated assembler in
> order for us to better understand the rationale?

Yes, this was caused by https://reviews.llvm.org/rL315899; the changes were for "better" rep/lock prefix support, but I filed several severe regression bugs, after noticing these during world and ports builds, see:
* https://bugs.llvm.org/show_bug.cgi?id=35741 (comments after x86 prefixes cause errors )
* https://bugs.llvm.org/show_bug.cgi?id=35749 (.byte directives after x86 prefixes cause errors)
* https://bugs.llvm.org/show_bug.cgi?id=35831 (labels after x86 prefixes cause errors)

The first bug was fixed fairly quickly, but there has been no movement on the other two, and I think it is likely that more edge cases exist.

I asked in PR35749 whether the release manager will consider reverting the upstream change in the 6.0.0 branch, since this regressed so much.  I will ask again.


> (In reply to Jung-uk Kim from comment #6)
> (In reply to Jan Beich from comment #4)
> 
> That's bad. :-(
> 
> Then, I guess we have no choice but to do something like this:
> 
> +-#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
> ++#define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; .byte 0xf0; 1: "

Yes, that is the workaround I put in my local ports tree too.  But I hate it :(
Comment 8 Jan Beich freebsd_committer freebsd_triage 2018-01-11 23:44:09 UTC
Dimitry, does openjdk8 actually work for you? Clang 6 probably misoptimizes it.

$ gdb -q /usr/local/openjdk8/bin/java
Reading symbols from /usr/local/openjdk8/bin/java...(no debugging symbols found)...done.
(gdb) r
Starting program: /usr/local/openjdk8/bin/java

Program received signal SIGSEGV, Segmentation fault.
0x00000008023c7896 in NativeCallStack::NativeCallStack(int, bool) ()
   from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
(gdb) bt
#0  0x00000008023c7896 in NativeCallStack::NativeCallStack(int, bool) ()
   from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#1  0x0000000802382f4e in MemTracker::init_tracking_level() ()
   from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#2  0x0000000801ebccb2 in ResourceObj::operator new(unsigned long, ResourceObj::allocation_type, MemoryType) () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#3  0x000000080245bb2a in _GLOBAL__sub_I_reflectionUtils.cpp ()
   from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#4  0x0000000802588ff2 in __do_global_ctors_aux ()
   from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#5  0x0000000801df331e in _init () from /usr/local/openjdk8/jre/lib/amd64/server/libjvm.so
#6  0x00007fffffffd110 in ?? ()
#7  0x00000008006056ba in objlist_call_init (list=<optimized out>, lockstate=<optimized out>)
    at /usr/src/libexec/rtld-elf/rtld.c:2672
#8  0x0000000800609e39 in dlopen_object (name=0x800629400 "z\270P\325", fd=<optimized out>,
    refobj=<optimized out>, lo_flags=2, mode=258, lockstate=0x2)
    at /usr/src/libexec/rtld-elf/rtld.c:3391
#9  0x0000000800606836 in rtld_dlopen (
    name=0x7fffffffe6d0 "/usr/local/openjdk8/jre/lib/amd64/server/libjvm.so", fd=-1,
    mode=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:3266
#10 0x00000008008293fe in LoadJavaVM () from /usr/local/openjdk8/bin/../lib/amd64/jli/libjli.so
#11 0x0000000800824d88 in JLI_Launch () from /usr/local/openjdk8/bin/../lib/amd64/jli/libjli.so
#12 0x00000000004008ab in main ()
Comment 9 Dimitry Andric freebsd_committer freebsd_triage 2018-01-12 20:50:30 UTC
(In reply to Jan Beich from comment #8)
> Dimitry, does openjdk8 actually work for you? Clang 6 probably misoptimizes
> it.

Not sure about misoptimizing, but it does indeed crash:

Program received signal SIGSEGV, Segmentation fault.
NativeCallStack::NativeCallStack (this=0x800e6a7a0 <NativeCallStack::EMPTY_STACK>, toSkip=0, fillStack=false)
    at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp:33
33        _hash_value(0) {
(gdb) bt
#0  NativeCallStack::NativeCallStack (this=0x800e6a7a0 <NativeCallStack::EMPTY_STACK>, toSkip=0, fillStack=false)
    at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp:33
#1  0x0000000801732d7e in MemTracker::init_tracking_level () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/services/memTracker.cpp:72
#2  0x000000080126cb62 in MemTracker::tracking_level () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/services/memTracker.hpp:118
#3  ResourceObj::operator new (size=32, type=ResourceObj::STACK_OR_EMBEDDED, flags=mtInternal) at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/memory/allocation.cpp:89
#4  0x000000080180b93a in _GLOBAL__sub_I_reflectionUtils.cpp () at /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/reflectionUtils.cpp:72
#5  0x0000000801939182 in __do_global_ctors_aux () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so
#6  0x00000008019391a6 in _init () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so
#7  0x00007fffffffc8f0 in ?? ()
#8  0x000000080020d06a in objlist_call_init (list=<optimized out>, lockstate=<optimized out>) at /usr/src/libexec/rtld-elf/rtld.c:2672
#9  0x00000008002117e9 in dlopen_object (name=0x80022f800 "z\270P\325", fd=<optimized out>, refobj=<optimized out>, lo_flags=2, mode=258, lockstate=0x772f386b00000002) at /usr/src/libexec/rtld-elf/rtld.c:3391
#10 0x000000080020e1e6 in rtld_dlopen (name=0x7fffffffdeb0 "/wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/lib/amd64/server/libjvm.so", fd=-1, mode=<optimized out>)
    at /usr/src/libexec/rtld-elf/rtld.c:3266
#11 0x000000080025136e in LoadJavaVM () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/bin/../lib/amd64/jli/libjli.so
#12 0x000000080024ccf8 in JLI_Launch () from /wrkdirs/share/dim/ports/java/openjdk8/work/openjdk/build/bsd-x86_64-normal-server-release/jdk/bin/../lib/amd64/jli/libjli.so
#13 0x000000000020130b in main ()
(gdb) print *this
$2 = {<StackObj> = {<No data fields>}, static EMPTY_STACK = {<StackObj> = {<No data fields>}, static EMPTY_STACK = <same as static member of an already seen type>, _stack = {0x0, 0x0, 0x0, 0x0}, _hash_value = 0},
  _stack = {0x0, 0x0, 0x0, 0x0}, _hash_value = 0}
(gdb) disassemble
Dump of assembler code for function NativeCallStack::NativeCallStack(int, bool):
   0x00000008017776c0 <+0>:     push   %rbp
   0x00000008017776c1 <+1>:     mov    %rsp,%rbp
   0x00000008017776c4 <+4>:     mov    %esi,%eax
=> 0x00000008017776c6 <+6>:     movl   $0x0,0x20(%rdi)
   0x00000008017776cd <+13>:    test   %edx,%edx
   0x00000008017776cf <+15>:    je     0x8017776de <NativeCallStack::NativeCallStack(int, bool)+30>
   0x00000008017776d1 <+17>:    mov    $0x4,%esi
   0x00000008017776d6 <+22>:    mov    %eax,%edx
   0x00000008017776d8 <+24>:    pop    %rbp
   0x00000008017776d9 <+25>:    jmpq   0x8017aa290 <os::get_native_stack(unsigned char**, int, int)>
   0x00000008017776de <+30>:    xorps  %xmm0,%xmm0
   0x00000008017776e1 <+33>:    movups %xmm0,0x10(%rdi)
   0x00000008017776e5 <+37>:    movups %xmm0,(%rdi)
   0x00000008017776e8 <+40>:    pop    %rbp
   0x00000008017776e9 <+41>:    retq
End of assembler dump.
(gdb) print &this->_hash_value
$4 = (int *) 0x800e6a7c0 <NativeCallStack::EMPTY_STACK+32>
(gdb) info registers
rax            0x0      0
rbx            0x0      0
rcx            0x0      0
rdx            0x0      0
rsi            0x0      0
rdi            0x800e6a7a0      34374854560
rbp            0x7fffffffc320   0x7fffffffc320
rsp            0x7fffffffc320   0x7fffffffc320
r8             0xfffffff5       4294967285
r9             0xffffffff81c1b688       -2118011256
r10            0x800e72e5c      34374889052
r11            0x7fffffffc0c8   140737488339144
r12            0x80022f9f0      34362030576
r13            0x2      2
r14            0x7fffffffc370   140737488339824
r15            0x8006a8a40      34366720576
rip            0x8017776c6      0x8017776c6 <NativeCallStack::NativeCallStack(int, bool)+6>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x43     67
ss             0x3b     59
ds             <unavailable>
es             <unavailable>
fs             <unavailable>
gs             <unavailable>
fs_base        0x8002318b0      34362038448
gs_base        0x0      0

So the address of the _hash_value field is OK, apparently.  As to why this gives a segfault, no idea yet.
Comment 10 Dimitry Andric freebsd_committer freebsd_triage 2018-01-12 21:20:07 UTC
(In reply to Dimitry Andric from comment #9)
> So the address of the _hash_value field is OK, apparently.  As to why this
> gives a segfault, no idea yet.

Actually, it is quite clear: the memory is read-only.  openjdk/hotspot/src/share/vm/utilities/nativeCallStack.cpp has:

28      #include "utilities/nativeCallStack.hpp"
29
30      const NativeCallStack NativeCallStack::EMPTY_STACK(0, false);
31
32      NativeCallStack::NativeCallStack(int toSkip, bool fillStack) :
33        _hash_value(0) {
34

I.e. NativeCallStack::EMPTY_STACK is const, and placed into .rodata.  Then openjdk/hotspot/src/share/vm/services/memTracker.cpp has:

70        // Construct NativeCallStack::EMPTY_STACK. It may get constructed twice,
71        // but it is benign, the results are the same.
72        ::new ((void*)&NativeCallStack::EMPTY_STACK) NativeCallStack(0, false);

This new invocation cannot work, because it tries to re-initialize a const object.  Why this worked in previous clang, or in any other compiler, I don't know. :)
Comment 11 Dimitry Andric freebsd_committer freebsd_triage 2018-01-12 21:36:52 UTC
The upstream commit that causes this problem is here:

http://hg.openjdk.java.net/jdk/hs/rev/35e11b657728

They apparently used to have a r/w emptyStack variable in their memTracker.cpp, but due to some issue with a "minimal build" (whatever that is), they started explicitly initializing it using placement new.

However, they also moved the variable into the NativeCallStack class, but as a static const member!  That simply cannot be right in any way.
Comment 12 Dimitry Andric freebsd_committer freebsd_triage 2018-01-13 00:15:54 UTC
Created attachment 189672 [details]
clang 6 fixes for openjdk8

With the attached patch, I can build and run openjdk8.  I have built a few openjdk8-dependent ports, and ran them with light testing, all seems to work fine.

1) patch-hotspot_src_os__cpu_bsd__x86_vm_atomic__bsd__x86.inline.hpp: replaces a lock prefix before a label with a .byte directive
2) patch-hotspot_src_os__cpu_bsd__x86_vm_bsd__x86__32.s: idem
3) patch-hotspot_src_share_vm_services_memTracker.cpp: removes the placement new that tries to reinitialize a static const object
Comment 13 Dimitry Andric freebsd_committer freebsd_triage 2018-01-17 17:24:12 UTC
base r328090 should fix the issues with the LOCK_IF_MP macro.  For some reason, bugzilla hasn't picked up the PR: line, though.
Comment 14 commit-hook freebsd_committer freebsd_triage 2018-01-18 01:59:15 UTC
A commit references this bug:

Author: jkim
Date: Thu Jan 18 01:58:20 UTC 2018
New revision: 459311
URL: https://svnweb.freebsd.org/changeset/ports/459311

Log:
  Fix build with Clang 6.0.

  Note it is partially merged from the upstream patches for Linux and GCC 6.

  https://bugs.openjdk.java.net/browse/JDK-8163032
  http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e34324d73cd5
  http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9e1264f51bae

  PR:		225054

Changes:
  head/java/openjdk7/files/patch-hotspot_make_bsd_makefiles_gcc.make
  head/java/openjdk7/files/patch-jdk_make_common_Defs-bsd.gmk
Comment 15 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-18 02:00:37 UTC
(In reply to Dimitry Andric from comment #13)
Yes, base r328090 fixed the problem.  Thanks!
Comment 16 Jan Beich freebsd_committer freebsd_triage 2018-01-18 02:39:21 UTC
Do you mean comment 9 disappeared on its own?
Comment 17 Dimitry Andric freebsd_committer freebsd_triage 2018-01-18 07:21:46 UTC
(In reply to Jan Beich from comment #16)
> Do you mean comment 9 disappeared on its own?

No, only the "unknown token in expression" asm compile error has been fixed by that.  The segfault must still be fixed, I guess?
Comment 18 Antoine Brodin freebsd_committer freebsd_triage 2018-01-18 10:00:38 UTC
Re-open,  the segfault wasn't fixed.
Comment 19 Dimitry Andric freebsd_committer freebsd_triage 2018-01-18 11:31:02 UTC
Created attachment 189881 [details]
Fix attempt to reinitialize read-only memory

(In reply to Antoine Brodin from comment #18)
> Re-open,  the segfault wasn't fixed.

Indeed, please also apply the patch for hotspot/src/share/vm/services/memTracker.cpp, otherwise it will still attempt to reinitialize read-only memory.
Comment 20 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-18 17:35:00 UTC
*** Bug 225249 has been marked as a duplicate of this bug. ***
Comment 21 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-18 17:41:31 UTC
(In reply to Dimitry Andric from comment #19)
Okay, I'll take care of this.
Comment 22 commit-hook freebsd_committer freebsd_triage 2018-01-18 19:27:16 UTC
A commit references this bug:

Author: jkim
Date: Thu Jan 18 19:26:27 UTC 2018
New revision: 459368
URL: https://svnweb.freebsd.org/changeset/ports/459368

Log:
  Fix a run-time crash with Clang 6.0.

  Note this problem was introduced with fixes for JDK-8055007.

  https://bugs.java.com/view_bug.do?bug_id=8055007
  http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/changeset/c6211b707068

  PR:		225054

Changes:
  head/java/openjdk8/Makefile
  head/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp
Comment 23 Jung-uk Kim freebsd_committer freebsd_triage 2018-01-18 19:29:56 UTC
Committed, thanks!
Comment 24 commit-hook freebsd_committer freebsd_triage 2018-02-23 18:15:44 UTC
A commit references this bug:

Author: swills
Date: Fri Feb 23 18:15:00 UTC 2018
New revision: 462712
URL: https://svnweb.freebsd.org/changeset/ports/462712

Log:
  MFH: r459311

  Fix build with Clang 6.0.

  Note it is partially merged from the upstream patches for Linux and GCC 6.

  https://bugs.openjdk.java.net/browse/JDK-8163032
  http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/rev/e34324d73cd5
  http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/9e1264f51bae

  PR:		225054

  Approved by:	ports-secteam (implicit)

Changes:
_U  branches/2018Q1/
  branches/2018Q1/java/openjdk7/files/patch-hotspot_make_bsd_makefiles_gcc.make
  branches/2018Q1/java/openjdk7/files/patch-jdk_make_common_Defs-bsd.gmk
Comment 25 commit-hook freebsd_committer freebsd_triage 2018-02-23 18:16:50 UTC
A commit references this bug:

Author: swills
Date: Fri Feb 23 18:15:54 UTC 2018
New revision: 462713
URL: https://svnweb.freebsd.org/changeset/ports/462713

Log:
  MFH: r459368

  Fix a run-time crash with Clang 6.0.

  Note this problem was introduced with fixes for JDK-8055007.

  https://bugs.java.com/view_bug.do?bug_id=8055007
  http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/changeset/c6211b707068

  PR:		225054

  Approved by:	ports-secteam (implicit)

Changes:
_U  branches/2018Q1/
  branches/2018Q1/java/openjdk8/Makefile
  branches/2018Q1/java/openjdk8/files/patch-hotspot_src_share_vm_services_memTracker.cpp