From david.holmes at oracle.com Mon Jan 2 23:53:44 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Jan 2017 09:53:44 +1000
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <58666849.1020700@linux.vnet.ibm.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
Message-ID: <b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
Seems fine.
Thanks,
David
On 30/12/2016 11:59 PM, Gustavo Romero wrote:
> Hi,
>
> That change is already reviewed by Martin on the ppc-aix-port ML [1], but since
> I understand that a formal review has to be submitted to the hs ML I resent it.
>
> Is any thing missing on my side?
>
> Thank you.
>
>
> Regards,
> Gustavo
>
> [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>
> On 15-12-2016 19:03, Gustavo Romero wrote:
>> Hi,
>>
>> Could the following change be reviewed please?
>>
>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>
>> Thank you.
>>
>>
>> Regards,
>> Gustavo
>>
>
From volker.simonis at gmail.com Tue Jan 3 18:08:14 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 3 Jan 2017 19:08:14 +0100
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
<b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
Message-ID: <CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
Hi David,
thanks for looking at this change.
As this is ppc64-only, I'll sponsor it.
Regards,
Volker
On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
> Seems fine.
>
> Thanks,
> David
>
>
> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>
>> Hi,
>>
>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>> since
>> I understand that a formal review has to be submitted to the hs ML I
>> resent it.
>>
>> Is any thing missing on my side?
>>
>> Thank you.
>>
>>
>> Regards,
>> Gustavo
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>
>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>
>>> Hi,
>>>
>>> Could the following change be reviewed please?
>>>
>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>
>>> Thank you.
>>>
>>>
>>> Regards,
>>> Gustavo
>>>
>>
>
From vladimir.kozlov at oracle.com Tue Jan 3 18:53:55 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 3 Jan 2017 10:53:55 -0800
Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now
Message-ID: <586BF343.7040608@oracle.com>
We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs fixes. Note for Hotspot it started week ago.
http://openjdk.java.net/projects/jdk9/
Please, make sure bugs you are planning to fix have P1-P3 priority and "fix version" is jdk 9. I just updated JDK-8171266 [1] for that.
You can rise priority to P3 if you think a bug must be fixed in jdk 9 or defer it to jdk 10 - set "fix version" to 10.
I see 3 aarch64 P4-P5 bugs which should be updated accordingly:
https://bugs.openjdk.java.net/browse/JDK-8170101
https://bugs.openjdk.java.net/browse/JDK-8170103
https://bugs.openjdk.java.net/browse/JDK-8165058
Thanks,
Vladimir
[1] https://bugs.openjdk.java.net/browse/JDK-8171266
"PPC64: Add support to -XX:RTMSpinLoopCount=0"
From david.holmes at oracle.com Wed Jan 4 03:11:27 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 13:11:27 +1000
Subject: MethodHandle initialization process - problem with JVM TI early VM
start event
Message-ID: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
We have encountered a crash in a JVM TI test, starting with b148, that
is caused by the attempted use of MethodRefs and invoke_dynamic within
class loading that occurs from the "early VM start" JVM TI event
callback - which happens before the VM and core classes are fully
initialized. The class being loaded/initialized is in java.base and so
this is allowed. The class, java.net.Authenticator, was changed in b148
to have static initialization involving method refs and hence the
problem was introduced.
I've included a stack dump below.
It is far from clear to me where responsibility for this lies, or even
how to narrow that down. Is it in the code of MethodHandleNatives? Or is
it in the VM linking/resolution code?
Thoughts appreciated. :)
Thanks,
David
-----
--------------- T H R E A D ---------------
Current thread (0x00007ff99c01c000): JavaThread "Unknown thread"
[_thread_in_vm, id=31105, stack(0x00007ff9a5584000,0x00007ff9a5684000)]
Stack: [0x00007ff9a5584000,0x00007ff9a5684000], sp=0x00007ff9a56809e0,
free space=1010k
Native frames: (J=compiled Java code, A=aot compiled Java code,
j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x16b1932] VMError::report_and_die(int, char const*, char
const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char cons
t*, int, unsigned long)+0x162
V [libjvm.so+0x16b26af] VMError::report_and_die(Thread*, char const*,
int, char const*, char const*, __va_list_tag*)+0x2f
V [libjvm.so+0xaa0fed] report_vm_error(char const*, int, char const*,
char const*, ...)+0xdd
V [libjvm.so+0x110fbd6]
LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle
const&, KlassHandle, Handle, KlassHandle, bool, Th
read*)+0x1f6
V [libjvm.so+0x11128b5] LinkResolver::resolve_invokevirtual(CallInfo&,
Handle, constantPoolHandle const&, int, Thread*)+0x185
V [libjvm.so+0x1113c5b] LinkResolver::resolve_invoke(CallInfo&, Handle,
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab
V [libjvm.so+0xdea7da] InterpreterRuntime::resolve_invoke(JavaThread*,
Bytecodes::Code)+0x23a
V [libjvm.so+0xdf69bb]
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xeb
j java.lang.invoke.MethodHandleNatives.<clinit>()V+2 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c]
InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0x110dd0c] LinkResolver::resolve_static_call(CallInfo&,
LinkInfo const&, bool, Thread*)+0x14c
V [libjvm.so+0xe13e3a] JavaCalls::call_static(JavaValue*, KlassHandle,
Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13a
V [libjvm.so+0x15bd833]
SystemDictionary::find_method_handle_type(Symbol*, KlassHandle,
Thread*)+0x10f3
V [libjvm.so+0x15be1c6]
SystemDictionary::link_method_handle_constant(KlassHandle, int,
KlassHandle, Symbol*, Symbol*, Thread*)+0x596
V [libjvm.so+0xa8ad46]
ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int,
int, Thread*)+0x7d6
V [libjvm.so+0xa8b7ad]
ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle
const&, int, Thread*)+0x16d
V [libjvm.so+0x11135db] LinkResolver::resolve_invokedynamic(CallInfo&,
constantPoolHandle const&, int, Thread*)+0x71b
V [libjvm.so+0x1113d2e] LinkResolver::resolve_invoke(CallInfo&, Handle,
constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x17e
V [libjvm.so+0xdebb64]
InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x274
V [libjvm.so+0xdf69a8]
InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xd8
j java.net.Authenticator.<clinit>()V+0 java.base
v ~StubRoutines::call_stub
V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
const&, JavaCallArguments*, Thread*)+0x950
V [libjvm.so+0xdcd15c]
InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
Thread*)+0x15c
V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
V [libjvm.so+0xdcd762]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
.part.160]+0x4a2
V [libjvm.so+0xdcdd2b]
InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
V [libjvm.so+0xf331f2] find_class_from_class_loader(JNIEnv_*, Symbol*,
unsigned char, Handle, Handle, unsigned char, Thread*)+0x122
V [libjvm.so+0xec0369] jni_FindClass+0x5e9
C [libjckjvmti.so+0x60d69] vmse00101_VMStart+0x2b
V [libjvm.so+0x107ce3b] JvmtiExport::post_early_vm_start()+0xcb
V [libjvm.so+0x16150ee] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4de
From david.holmes at oracle.com Wed Jan 4 07:03:44 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 17:03:44 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
VM start event
In-Reply-To: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
Message-ID: <bf064b64-6c67-a895-bab3-b3d6f3a1e854@oracle.com>
Looking further into this the crash occurs because java.lang.Class has
not been initialized yet. Logging shows we go straight from initializing
Object to initializing java.net.Authenticator then to
java.lang.invoke.MethodHandleNatives.
[3.484s][debug][vtables ] Initializing: java/lang/invoke/MethodHandleNatives
[3.484s][trace][vtables ] copy vtable from java.lang.Object to
java.lang.invoke.MethodHandleNatives size 5
[3.484s][info ][class,init ] 2 Initializing
'java/lang/invoke/MethodHandleNatives' (0x000000080000c608)
[3.485s][debug][class,resolve ] java.lang.invoke.MethodHandleNatives
java.lang.Class MethodHandleNatives.java:44
[3.485s][trace][vtables ] invokevirtual resolved method:
caller-class:java.lang.invoke.MethodHandleNatives,
compile-time-class:java.lang.Class,
method:java.lang.Class.desiredAssertionStatus()Z,
method_holder:java.lang.Class, access_flags: public
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/linkResolver.cpp:1295
But why we are not implicitly initializing java.lang.Class before the
invokevirtual processing?
The clinit for MethodHandleNatives starts with:
static {};
descriptor: ()V
flags: (0x0008) ACC_STATIC
Code:
stack=3, locals=2, args_size=0
0: ldc #160 // class java/lang/invoke/MethodHandleNatives
2: invokevirtual #161 // Method
java/lang/Class.desiredAssertionStatus:()Z
A class must be initialized before we may invoke a method on it, or
obtain an instance - so why is nothing ensuring java.lang.Class is
initialized?
David
-----
On 4/01/2017 1:11 PM, David Holmes wrote:
> We have encountered a crash in a JVM TI test, starting with b148, that
> is caused by the attempted use of MethodRefs and invoke_dynamic within
> class loading that occurs from the "early VM start" JVM TI event
> callback - which happens before the VM and core classes are fully
> initialized. The class being loaded/initialized is in java.base and so
> this is allowed. The class, java.net.Authenticator, was changed in b148
> to have static initialization involving method refs and hence the
> problem was introduced.
>
> I've included a stack dump below.
>
> It is far from clear to me where responsibility for this lies, or even
> how to narrow that down. Is it in the code of MethodHandleNatives? Or is
> it in the VM linking/resolution code?
>
> Thoughts appreciated. :)
>
> Thanks,
> David
> -----
>
>
> --------------- T H R E A D ---------------
>
> Current thread (0x00007ff99c01c000): JavaThread "Unknown thread"
> [_thread_in_vm, id=31105, stack(0x00007ff9a5584000,0x00007ff9a5684000)]
>
> Stack: [0x00007ff9a5584000,0x00007ff9a5684000], sp=0x00007ff9a56809e0,
> free space=1010k
> Native frames: (J=compiled Java code, A=aot compiled Java code,
> j=interpreted, Vv=VM code, C=native code)
> V [libjvm.so+0x16b1932] VMError::report_and_die(int, char const*, char
> const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char cons
> t*, int, unsigned long)+0x162
> V [libjvm.so+0x16b26af] VMError::report_and_die(Thread*, char const*,
> int, char const*, char const*, __va_list_tag*)+0x2f
> V [libjvm.so+0xaa0fed] report_vm_error(char const*, int, char const*,
> char const*, ...)+0xdd
> V [libjvm.so+0x110fbd6]
> LinkResolver::runtime_resolve_virtual_method(CallInfo&, methodHandle
> const&, KlassHandle, Handle, KlassHandle, bool, Th
> read*)+0x1f6
> V [libjvm.so+0x11128b5] LinkResolver::resolve_invokevirtual(CallInfo&,
> Handle, constantPoolHandle const&, int, Thread*)+0x185
> V [libjvm.so+0x1113c5b] LinkResolver::resolve_invoke(CallInfo&, Handle,
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0xab
> V [libjvm.so+0xdea7da] InterpreterRuntime::resolve_invoke(JavaThread*,
> Bytecodes::Code)+0x23a
> V [libjvm.so+0xdf69bb]
> InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xeb
> j java.lang.invoke.MethodHandleNatives.<clinit>()V+2 java.base
> v ~StubRoutines::call_stub
> V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
> const&, JavaCallArguments*, Thread*)+0x950
> V [libjvm.so+0xdcd15c]
> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0x15c
> V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
> V [libjvm.so+0xdcd762]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
> .part.160]+0x4a2
> V [libjvm.so+0xdcdd2b]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
> V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
> V [libjvm.so+0x110dd0c] LinkResolver::resolve_static_call(CallInfo&,
> LinkInfo const&, bool, Thread*)+0x14c
> V [libjvm.so+0xe13e3a] JavaCalls::call_static(JavaValue*, KlassHandle,
> Symbol*, Symbol*, JavaCallArguments*, Thread*)+0x13a
> V [libjvm.so+0x15bd833]
> SystemDictionary::find_method_handle_type(Symbol*, KlassHandle,
> Thread*)+0x10f3
> V [libjvm.so+0x15be1c6]
> SystemDictionary::link_method_handle_constant(KlassHandle, int,
> KlassHandle, Symbol*, Symbol*, Thread*)+0x596
> V [libjvm.so+0xa8ad46]
> ConstantPool::resolve_constant_at_impl(constantPoolHandle const&, int,
> int, Thread*)+0x7d6
> V [libjvm.so+0xa8b7ad]
> ConstantPool::resolve_bootstrap_specifier_at_impl(constantPoolHandle
> const&, int, Thread*)+0x16d
> V [libjvm.so+0x11135db] LinkResolver::resolve_invokedynamic(CallInfo&,
> constantPoolHandle const&, int, Thread*)+0x71b
> V [libjvm.so+0x1113d2e] LinkResolver::resolve_invoke(CallInfo&, Handle,
> constantPoolHandle const&, int, Bytecodes::Code, Thread*)+0x17e
> V [libjvm.so+0xdebb64]
> InterpreterRuntime::resolve_invokedynamic(JavaThread*)+0x274
> V [libjvm.so+0xdf69a8]
> InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0xd8
> j java.net.Authenticator.<clinit>()V+0 java.base
> v ~StubRoutines::call_stub
> V [libjvm.so+0xe15970] JavaCalls::call_helper(JavaValue*, methodHandle
> const&, JavaCallArguments*, Thread*)+0x950
> V [libjvm.so+0xdcd15c]
> InstanceKlass::call_class_initializer_impl(instanceKlassHandle,
> Thread*)+0x15c
> V [libjvm.so+0xdcd2a3] InstanceKlass::call_class_initializer(Thread*)+0x83
> V [libjvm.so+0xdcd762]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*) [clone
> .part.160]+0x4a2
> V [libjvm.so+0xdcdd2b]
> InstanceKlass::initialize_impl(instanceKlassHandle, Thread*)+0x13b
> V [libjvm.so+0xdcde72] InstanceKlass::initialize(Thread*)+0x102
> V [libjvm.so+0xf331f2] find_class_from_class_loader(JNIEnv_*, Symbol*,
> unsigned char, Handle, Handle, unsigned char, Thread*)+0x122
> V [libjvm.so+0xec0369] jni_FindClass+0x5e9
> C [libjckjvmti.so+0x60d69] vmse00101_VMStart+0x2b
> V [libjvm.so+0x107ce3b] JvmtiExport::post_early_vm_start()+0xcb
> V [libjvm.so+0x16150ee] Threads::create_vm(JavaVMInitArgs*, bool*)+0x4de
From Alan.Bateman at oracle.com Wed Jan 4 08:45:38 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 08:45:38 +0000
Subject: MethodHandle initialization process - problem with JVM TI early
VM start event
In-Reply-To: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
Message-ID: <a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
On 04/01/2017 03:11, David Holmes wrote:
> We have encountered a crash in a JVM TI test, starting with b148, that
> is caused by the attempted use of MethodRefs and invoke_dynamic within
> class loading that occurs from the "early VM start" JVM TI event
> callback - which happens before the VM and core classes are fully
> initialized. The class being loaded/initialized is in java.base and so
> this is allowed. The class, java.net.Authenticator, was changed in
> b148 to have static initialization involving method refs and hence the
> problem was introduced.
>
> I've included a stack dump below.
>
> It is far from clear to me where responsibility for this lies, or even
> how to narrow that down. Is it in the code of MethodHandleNatives? Or
> is it in the VM linking/resolution code?
>
> Thoughts appreciated. :)
Ugh, this looks like the callback for the VMStart event is triggering
the execution of arbitrary code via its initializer. When the
can_generate_early_vmstart capability is enabled then the VMStart event
is posted before the system classes are initialized (before
Threads::initialize_java_lang_classes is called). If the callbacks uses
JNI FindClass to load classes in java.base (it's restricted to java.base
in this phase) then it will trigger the execution of random bytecode
with all sort of consequences. Even if the system classes are
initialized then it can still cause all sorts of issues - e.g.
triggering code in classes such as ResourceBundle and elsewhere that
depend on the system class loader to be initialized. For the specific
crash then it looks like MethodHandleNatives has asserts and so
Class::desiredAssertionStatus will be invoked to test if assertions are
enabled but, as I say, there are lots of other reasons that would cause
random classes in java.base to fail when invoked before the system
classes are initialized.
The reason this event is called so early is to allow native (not java)
agents get other events during startup. Also it's not new that this
event is posted before the system classes are initialized, you'll see
the same with JDK 8 and older because VMStart was always posted very
early. In JDK 9 then the VMStart is only posted early when the
can_generate_early_vmstart capability is enabled. This chage.
As regards fixing this then I don't think it would be unreasonable to
put some restrictions on what can be done in the VMStart callback when
can_generate_early_vmstart capability is enabled. Maybe it could be just
further re-wording of the paragraph on what can be done in this phase
rather than trying to enforce it.
-Alan
From volker.simonis at gmail.com Wed Jan 4 10:23:04 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 4 Jan 2017 11:23:04 +0100
Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now
In-Reply-To: <586BF343.7040608@oracle.com>
References: <586BF343.7040608@oracle.com>
Message-ID: <CA+3eh10QhjK5KQ8Fsx3XZYdc6Lor7ShdUp5ZujTkYZ4hACPYsA@mail.gmail.com>
On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs
> fixes. Note for Hotspot it started week ago.
>
> http://openjdk.java.net/projects/jdk9/
>
> Please, make sure bugs you are planning to fix have P1-P3 priority and "fix
> version" is jdk 9. I just updated JDK-8171266 [1] for that.
>
Thanks a lot Vladimir. I'll push it today.
Just for clarification: do the "Rampdown phase rules" also apply to
non-Oracle platforms like ppc64 or s390x? In the past, we were allowed
to push non P1-P3 bugs or enhancements even in later phases as long as
they didn't touch shared code. Is this still allowed or do we now have
to strictly conform to the process even for ppc64/s390x-only changes?
Thanks a lot and best regards,
Volker
> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or
> defer it to jdk 10 - set "fix version" to 10.
>
> I see 3 aarch64 P4-P5 bugs which should be updated accordingly:
>
> https://bugs.openjdk.java.net/browse/JDK-8170101
> https://bugs.openjdk.java.net/browse/JDK-8170103
> https://bugs.openjdk.java.net/browse/JDK-8165058
>
> Thanks,
> Vladimir
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8171266
> "PPC64: Add support to -XX:RTMSpinLoopCount=0"
>
From david.holmes at oracle.com Wed Jan 4 10:39:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Jan 2017 20:39:54 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
VM start event
In-Reply-To: <a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
Message-ID: <6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
Hi Alan,
On 4/01/2017 6:45 PM, Alan Bateman wrote:
> On 04/01/2017 03:11, David Holmes wrote:
>
>> We have encountered a crash in a JVM TI test, starting with b148, that
>> is caused by the attempted use of MethodRefs and invoke_dynamic within
>> class loading that occurs from the "early VM start" JVM TI event
>> callback - which happens before the VM and core classes are fully
>> initialized. The class being loaded/initialized is in java.base and so
>> this is allowed. The class, java.net.Authenticator, was changed in
>> b148 to have static initialization involving method refs and hence the
>> problem was introduced.
>>
>> I've included a stack dump below.
>>
>> It is far from clear to me where responsibility for this lies, or even
>> how to narrow that down. Is it in the code of MethodHandleNatives? Or
>> is it in the VM linking/resolution code?
>>
>> Thoughts appreciated. :)
> Ugh, this looks like the callback for the VMStart event is triggering
> the execution of arbitrary code via its initializer. When the
> can_generate_early_vmstart capability is enabled then the VMStart event
> is posted before the system classes are initialized (before
> Threads::initialize_java_lang_classes is called). If the callbacks uses
> JNI FindClass to load classes in java.base (it's restricted to java.base
> in this phase) then it will trigger the execution of random bytecode
> with all sort of consequences. Even if the system classes are
> initialized then it can still cause all sorts of issues - e.g.
> triggering code in classes such as ResourceBundle and elsewhere that
> depend on the system class loader to be initialized. For the specific
> crash then it looks like MethodHandleNatives has asserts and so
> Class::desiredAssertionStatus will be invoked to test if assertions are
> enabled but, as I say, there are lots of other reasons that would cause
> random classes in java.base to fail when invoked before the system
> classes are initialized.
Right.
> The reason this event is called so early is to allow native (not java)
> agents get other events during startup. Also it's not new that this
> event is posted before the system classes are initialized, you'll see
> the same with JDK 8 and older because VMStart was always posted very
> early. In JDK 9 then the VMStart is only posted early when the
> can_generate_early_vmstart capability is enabled. This chage.
>
> As regards fixing this then I don't think it would be unreasonable to
> put some restrictions on what can be done in the VMStart callback when
> can_generate_early_vmstart capability is enabled. Maybe it could be just
> further re-wording of the paragraph on what can be done in this phase
> rather than trying to enforce it.
That is my thought too, that the spec needs to give less of the
impression that it's okay to access java.base classes at this early VM
start event, and basically say that any form of class-loading is not
guaranteed to succeed and will quite likely crash the JVM.
The test can then be modified accordingly.
Thanks,
David
> -Alan
From Alan.Bateman at oracle.com Wed Jan 4 12:15:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 4 Jan 2017 12:15:30 +0000
Subject: MethodHandle initialization process - problem with JVM TI early
VM start event
In-Reply-To: <6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
<6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
Message-ID: <85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>
On 04/01/2017 10:39, David Holmes wrote:
>
> That is my thought too, that the spec needs to give less of the
> impression that it's okay to access java.base classes at this early VM
> start event, and basically say that any form of class-loading is not
> guaranteed to succeed and will quite likely crash the JVM.
The JVM TI spec has always allowed agents to call any JNI function in
the start phase. I don't think there was any intention to have agents
load and execute arbitrary java code but this wasn't fully spelled out.
For JDK 9 then we attempt to preserve this compatibility for existing
agents by deferring the start phase until after the module system is
initialized (initPhase2). This has the side effect that they miss out on
some interesting events during startup. They can of course replay at
least some of them with GenerateEvents but it's not enough for some
agents. So this is the reason for the can_generate_early_vmstart
capability and it's intended for agents that take an oath of carefulness.
So for the spec update then I think the restrictions can be mostly
limited to when the can_generate_early_vmstart capability is enabled.
Ideally we should avoid introducing yet another event that signals the
point in the start phase when it's safe to do things, agents can use the
VMInit for that.
-Alan
From vladimir.kozlov at oracle.com Wed Jan 4 19:30:38 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 4 Jan 2017 11:30:38 -0800
Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now
In-Reply-To: <CA+3eh10QhjK5KQ8Fsx3XZYdc6Lor7ShdUp5ZujTkYZ4hACPYsA@mail.gmail.com>
References: <586BF343.7040608@oracle.com>
<CA+3eh10QhjK5KQ8Fsx3XZYdc6Lor7ShdUp5ZujTkYZ4hACPYsA@mail.gmail.com>
Message-ID: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com>
On 1/4/17 2:23 AM, Volker Simonis wrote:
> On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs
>> fixes. Note for Hotspot it started week ago.
>>
>> http://openjdk.java.net/projects/jdk9/
>>
>> Please, make sure bugs you are planning to fix have P1-P3 priority and "fix
>> version" is jdk 9. I just updated JDK-8171266 [1] for that.
>>
>
> Thanks a lot Vladimir. I'll push it today.
>
> Just for clarification: do the "Rampdown phase rules" also apply to
> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed
> to push non P1-P3 bugs or enhancements even in later phases as long as
> they didn't touch shared code. Is this still allowed or do we now have
> to strictly conform to the process even for ppc64/s390x-only changes?
JDK 9 schedule was approved by all, including Java Community outside Oracle.
I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and there were no exceptions listed:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
But I understand that JDK 9 schedule reflects the process inside Oracle and may not be applied directly to your process.
I will try to clarify situation with your ports regarding JDK 9 schedule and inform you.
Regards,
Vladimir
>
> Thanks a lot and best regards,
> Volker
>
>> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or
>> defer it to jdk 10 - set "fix version" to 10.
>>
>> I see 3 aarch64 P4-P5 bugs which should be updated accordingly:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8170101
>> https://bugs.openjdk.java.net/browse/JDK-8170103
>> https://bugs.openjdk.java.net/browse/JDK-8165058
>>
>> Thanks,
>> Vladimir
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8171266
>> "PPC64: Add support to -XX:RTMSpinLoopCount=0"
>>
From Derek.White at cavium.com Wed Jan 4 23:02:18 2017
From: Derek.White at cavium.com (White, Derek)
Date: Wed, 4 Jan 2017 23:02:18 +0000
Subject: RFR: 8172157: Tighten up contract between concurrent GCs and runtime
regarding object allocation and header initialization
Message-ID: <6EFFB836-BD87-4113-9472-53FE60363511@cavium.com>
[resending to hotspot-dev]
There are three issues that came up in the review comments for 8171449<tel:8171449> that I tried to handle:
1) Inline allocation by jitted code and the interpreter only allocate out of the young gen (either TLABS or eden), and the concurrent GC threads will never scan object in the young gen, so inline-alloctors don't need to ensure memory ordering for the concurrent GC's use. Added comments and assertions.
2) Non-inline allocation in the old gen by a concurrent GC should first set an object?s klass field to NULL before setting it to a correct value. Added comments and assertions.
3) There should be no race condition between the steps in 2 that allows a concurrent GC thread to see an incorrect value. This is harder to prove, and is not handled in this fix.
I'm trying to pull some of the constraints out from the depths of the collectors to something closer to the GC/runtime interface, so the non-GC code (writers) can reason about it.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172157 ?Tighten up contract between concurrent GCs and runtime regarding object allocation and header initialization?
Webrev: http://cr.openjdk.java.net/~drwhite/8172157/webrev.02/
Thanks,
* Derek
From Derek.White at cavium.com Wed Jan 4 23:03:20 2017
From: Derek.White at cavium.com (White, Derek)
Date: Wed, 4 Jan 2017 23:03:20 +0000
Subject: RFR: 8172157: Tighten up contract between concurrent GCs and runtime
regarding object allocation and header initialization
Message-ID: <14C6611C-8758-4688-BAFE-FE96CD0DB0E5@cavium.com>
[resending to hotspot-dev]
There are three issues that came up in the review comments for 8171449<tel:8171449> that I tried to handle:
1) Inline allocation by jitted code and the interpreter only allocate out of the young gen (either TLABS or eden), and the concurrent GC threads will never scan object in the young gen, so inline-alloctors don't need to ensure memory ordering for the concurrent GC's use. Added comments and assertions.
2) Non-inline allocation in the old gen by a concurrent GC should first set an object?s klass field to NULL before setting it to a correct value. Added comments and assertions.
3) There should be no race condition between the steps in 2 that allows a concurrent GC thread to see an incorrect value. This is harder to prove, and is not handled in this fix.
I'm trying to pull some of the constraints out from the depths of the collectors to something closer to the GC/runtime interface, so the non-GC code (writers) can reason about it.
Bug: https://bugs.openjdk.java.net/browse/JDK-8172157 ?Tighten up contract between concurrent GCs and runtime regarding object allocation and header initialization?
Webrev: http://cr.openjdk.java.net/~drwhite/8172157/webrev.02/
Thanks,
* Derek
From kim.barrett at oracle.com Thu Jan 5 01:22:45 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Jan 2017 20:22:45 -0500
Subject: RFR: 8172157: Tighten up contract between concurrent GCs and
runtime regarding object allocation and header initialization
In-Reply-To: <6EFFB836-BD87-4113-9472-53FE60363511@cavium.com>
References: <6EFFB836-BD87-4113-9472-53FE60363511@cavium.com>
Message-ID: <F69D8E71-A7E4-48E5-A035-0D0DBC535DE6@oracle.com>
> On Jan 4, 2017, at 6:02 PM, White, Derek <Derek.White at cavium.com> wrote:
>
> [resending to hotspot-dev]
>
> There are three issues that came up in the review comments for 8171449 that I tried to handle:
> 1) Inline allocation by jitted code and the interpreter only allocate out of the young gen (either TLABS or eden), and the concurrent GC threads will never scan object in the young gen, so inline-alloctors don't need to ensure memory ordering for the concurrent GC's use. Added comments and assertions.
>
> 2) Non-inline allocation in the old gen by a concurrent GC should first set an object?s klass field to NULL before setting it to a correct value. Added comments and assertions.
> 3) There should be no race condition between the steps in 2 that allows a concurrent GC thread to see an incorrect value. This is harder to prove, and is not handled in this fix.
>
> I'm trying to pull some of the constraints out from the depths of the collectors to something closer to the GC/runtime interface, so the non-GC code (writers) can reason about it.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172157 ?Tighten up contract between concurrent GCs and runtime regarding object allocation and header initialization?
>
> Webrev: http://cr.openjdk.java.net/~drwhite/8172157/webrev.02/
>
> Thanks,
>
> ? Derek
Note that I think this sort of thing is an enhancement, rather than a
bug as the JIRA issue is presently categorized. Nothing is broken;
it's just harder to understand and modify the code than we might
prefer. As such, I think work along this line ought to be deferred
out of JDK 9.
------------------------------------------------------------------------------
src/share/vm/gc/shared/collectedHeap.hpp
132 // Concurrent collectors must never allocate a TLAB from the old generation,
133 // because inline-allocation in TLABS by jitted code does not enforce
134 // memory ordering consistency for store-length/store-klass, so concurrent GC
135 // could see inconsistent values when scanning the old gen.
This comment is wrong for a single generation concurent collector.
Such a collector might still support TLAB allocation for performance.
It would just have arrange to not look in the TLABs when that would be
a problem. Consider a SATB-based collector, where allocation is
black; do something like make TLAB portions from before start of mark
parsable, and don't scan objects in TLAB portions (possibly entire
TLABs) allocated from after start of marking. I think Shenandoah
might be an example of this, and similarly for a collector I worked on
for a former employer.
------------------------------------------------------------------------------
src/share/vm/gc/shared/genCollectedHeap.cpp
1019 assert(is_in_young((oop)result), "TLAB must be allocated in young gen");
I think this assertion is wrong, for the same reason I think the
comment for allocate_new_tlab is wrong.
------------------------------------------------------------------------------
src/share/vm/gc/shared/genCollectedHeap.cpp
492 assert(is_in_young((oop)result) ||
493 ((oop)result)->klass_or_null() == NULL,
494 "mem_allocate must clear (what will be) the klass field for non-young allocations");
I think a more accurate assertion regimen would be to verify
non-humongous allocations were made from the young gen, and humongous
allocations have the needed null klass location.
------------------------------------------------------------------------------
I'm generally suspicious of the proposed comments and assertions. I
think the actual contracts are not as simple :) as suggested by these
changes.
For example, for G1, some of the relevant requirements around setup
and ordering on the allocation side appear to be to support concurrent
refinement. If using the suggested G1 throughput mode (simpler
post-barrier, no concurrent refinement), some of those requirements
might be relaxed, though we might not conditionalize the code.
And for G1 generally, some of the ordering being done on the slow path
(such as ensuring the length of arrays and classes are set before
setting the klass field) is only needed when the object is humongous,
but again here the code isn't conditionalized.
So I think these kind of changes are premature. I think what is first
needed is some discussion of what the contracts really are, e.g. reify
the design that is presently implicit in the code. Ideally, this
should identify parts that are specific to certain GCs or GCs having
certain properties. Once we have that, then we can start talking
about how to feed that information back into the code, in the form of
assertions, conditionalizations, &etc.
An additional benefit of this would be discovery of code bits that
might be conditionalized as part of the GC abstration layer that has
been discussed recently. It might also help identify "shared" code
that is really CMS-specific, in support of CMS deprecation.
From david.holmes at oracle.com Thu Jan 5 02:01:32 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 12:01:32 +1000
Subject: MethodHandle initialization process - problem with JVM TI early
VM start event
In-Reply-To: <85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>
References: <9f70a9cd-5e34-1d3c-70ae-747eda747729@oracle.com>
<a19f2dfc-0aaf-1a63-d098-4c9ccbf96c24@oracle.com>
<6e9159e6-4ef0-01b7-5f9f-d949c846f57b@oracle.com>
<85144bff-a1b4-bb64-c138-8bec26ea5323@oracle.com>
Message-ID: <ee6a64b4-fd11-4d55-73f4-9c9dc6daf397@oracle.com>
Hi Alan,
On 4/01/2017 10:15 PM, Alan Bateman wrote:
> On 04/01/2017 10:39, David Holmes wrote:
>
>>
>> That is my thought too, that the spec needs to give less of the
>> impression that it's okay to access java.base classes at this early VM
>> start event, and basically say that any form of class-loading is not
>> guaranteed to succeed and will quite likely crash the JVM.
> The JVM TI spec has always allowed agents to call any JNI function in
> the start phase. I don't think there was any intention to have agents
> load and execute arbitrary java code but this wasn't fully spelled out.
Yes the spec has always been completely broken in this regard IMHO.
> For JDK 9 then we attempt to preserve this compatibility for existing
> agents by deferring the start phase until after the module system is
> initialized (initPhase2). This has the side effect that they miss out on
> some interesting events during startup. They can of course replay at
> least some of them with GenerateEvents but it's not enough for some
> agents. So this is the reason for the can_generate_early_vmstart
> capability and it's intended for agents that take an oath of carefulness.
Understood.
> So for the spec update then I think the restrictions can be mostly
> limited to when the can_generate_early_vmstart capability is enabled.
> Ideally we should avoid introducing yet another event that signals the
> point in the start phase when it's safe to do things, agents can use the
> VMInit for that.
My precise intent is to modify the text that was added in regard to the
can_generate_early_vmstart capability, and further reduce expectations
about what can be expected to work at that time. I have filed a new bug
to make this correction to the JVM TI spec:
https://bugs.openjdk.java.net/browse/JDK-8172261
Thanks,
David
> -Alan
From gromero at linux.vnet.ibm.com Thu Jan 5 02:03:04 2017
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 5 Jan 2017 00:03:04 -0200
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
<b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
<CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
Message-ID: <586DA958.3020104@linux.vnet.ibm.com>
Hi
On 03-01-2017 16:08, Volker Simonis wrote:
> Hi David,
>
> thanks for looking at this change.
> As this is ppc64-only, I'll sponsor it.
>
> Regards,
> Volker
David, thanks for reviewing the change.
Volker, thanks for sponsoring it.
Vladimir, thanks for setting the proper priority and fix version tag.
Regards,
Gustavo
> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>> Seems fine.
>>
>> Thanks,
>> David
>>
>>
>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>
>>> Hi,
>>>
>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>> since
>>> I understand that a formal review has to be submitted to the hs ML I
>>> resent it.
>>>
>>> Is any thing missing on my side?
>>>
>>> Thank you.
>>>
>>>
>>> Regards,
>>> Gustavo
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>
>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>
>>>> Hi,
>>>>
>>>> Could the following change be reviewed please?
>>>>
>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>
>>>> Thank you.
>>>>
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>
>>
>
From david.holmes at oracle.com Thu Jan 5 04:34:08 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 5 Jan 2017 14:34:08 +1000
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
Message-ID: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
Please review this backport of the fix for 8170888, it can't apply
cleanly due to use of unified logging, but that is the only change.
Original JDK 9 review thread:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
JDK 9 changeset:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
Thanks,
David
-----
From volker.simonis at gmail.com Thu Jan 5 13:18:25 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 5 Jan 2017 14:18:25 +0100
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <586DA958.3020104@linux.vnet.ibm.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
<b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
<CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
<586DA958.3020104@linux.vnet.ibm.com>
Message-ID: <CA+3eh12aGxWsUbaMCK9B_7_a+cbzys944Qi2=UF4_A5X2-G02w@mail.gmail.com>
Hi Gustavo,
I finally got a Power machine which supports RTM.
So before pushing this change, I thought I run the RTM jtreg tests.
Obviously your change improves the situation by preventing crashes
because of RTMSpinLoopCount=0. But I still get 10 failures when
running the RTM tests (test/compiler/rtm) on linux/ppc64:
compiler/rtm/locking/TestRTMAbortRatio.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get exit
value of [0]
compiler/rtm/locking/TestRTMAbortThreshold.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected that method with
rtm lock elision was deoptimized after 1 lock attempts: expected 10000
to equal 1
compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Two uncommon traps with
reason rtm_state_change should be fired.: expected 0 to equal 2
compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get only one
deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Expected to get only one
deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMLockingCalculationDelay.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: At least one
deoptimization due to rtm_state_chage is expected: expected 0 > 0
compiler/rtm/locking/TestRTMLockingThreshold.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: VM output should contain
two RTM locking statistics entries.: expected 1 to equal 2
compiler/rtm/locking/TestRTMRetryCount.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: It is expected to get 2
aborts: expected 3 to equal 2
compiler/rtm/locking/TestRTMSpinLoopCount.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: Total aborts count (2001)
should be less or equal to 1001: expected that 2001 <= 1001
compiler/rtm/locking/TestUseRTMXendForLockBusy.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: VM output should contain
exactly one rtm locking statistics entry for method
compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
Failed. Execution failed: `main'
threw exception: java.lang.RuntimeException: RTM locking statistics
should contain non zero total aborts count: expected 0 > 0
On the other hand, the situation on linux/x86_64 seems similar (with
7-9 failures depending on the run):
compiler/rtm/locking/TestRTMAbortThreshold.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Expected that
method with rtm lock elision was deoptimized after 1 lock attempts:
expected 10000 to equal 1
compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Two uncommon traps
with reason rtm_state_change should be fired.: expected 0 to equal 2
compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: Expected to get
only one deoptimization due to rtm state change: expected 0 to equal 1
compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: After
LockThreshold was reached, method should be recompiled with rtm lock
eliding.: expected null to not equal null
compiler/rtm/locking/TestRTMLockingCalculationDelay.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: At least one
deoptimization due to rtm_state_chage is expected: expected 0 > 0
compiler/rtm/locking/TestRTMLockingThreshold.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain two RTM locking statistics entries.: expected 1 to equal 2
compiler/rtm/locking/TestRTMTotalCountIncrRate.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain exactly one RTM locking statistics entry for method
compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
to equal 1
compiler/rtm/locking/TestUseRTMXendForLockBusy.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: VM output should
contain exactly one rtm locking statistics entry for method
compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
Failed. Execution failed:
`main' threw exception: java.lang.RuntimeException: RTM locking
statistics should contain non zero total aborts count: expected 0 > 0
Are these the same results you are seeing as well?
The JDK 9 Early Access Build Test Results site at
http://download.java.net/openjdk/testresults/9/testresults.html
reports these tests as passed, but I think that may be because they
run on hardware which doesn't support RTM?
@Vladimir, David: do you regularly run the RTM tests on linux/x86_64
and do they really all pass in your environment? (I've tested with
Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
coreinfo.exe both support RTM).
Thank you and best regards,
Volker
On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
<gromero at linux.vnet.ibm.com> wrote:
> Hi
>
> On 03-01-2017 16:08, Volker Simonis wrote:
>> Hi David,
>>
>> thanks for looking at this change.
>> As this is ppc64-only, I'll sponsor it.
>>
>> Regards,
>> Volker
>
> David, thanks for reviewing the change.
>
> Volker, thanks for sponsoring it.
>
> Vladimir, thanks for setting the proper priority and fix version tag.
>
>
> Regards,
> Gustavo
>
>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> Seems fine.
>>>
>>> Thanks,
>>> David
>>>
>>>
>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>
>>>> Hi,
>>>>
>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>> since
>>>> I understand that a formal review has to be submitted to the hs ML I
>>>> resent it.
>>>>
>>>> Is any thing missing on my side?
>>>>
>>>> Thank you.
>>>>
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>> [1]
>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>
>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Could the following change be reviewed please?
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>
>>>
>>
>
From george.triantafillou at oracle.com Thu Jan 5 14:27:38 2017
From: george.triantafillou at oracle.com (George Triantafillou)
Date: Thu, 5 Jan 2017 09:27:38 -0500
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
Message-ID: <12fa230b-4281-fb3b-7ea4-488075d31166@oracle.com>
Hi David,
Looks good!
-George
On 1/4/2017 11:34 PM, David Holmes wrote:
> Please review this backport of the fix for 8170888, it can't apply
> cleanly due to use of unified logging, but that is the only change.
>
> Original JDK 9 review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
>
> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
>
> Thanks,
> David
> -----
From karen.kinnear at oracle.com Thu Jan 5 17:59:51 2017
From: karen.kinnear at oracle.com (Karen Kinnear)
Date: Thu, 5 Jan 2017 12:59:51 -0500
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
Message-ID: <E3A1A446-E7CB-432F-B0B1-A5CAFEA64A03@oracle.com>
David,
Looks good!
thanks,
Karen
> On Jan 4, 2017, at 11:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Please review this backport of the fix for 8170888, it can't apply cleanly due to use of unified logging, but that is the only change.
>
> Original JDK 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>
> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
>
> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
>
> Thanks,
> David
> -----
From gromero at linux.vnet.ibm.com Thu Jan 5 20:18:09 2017
From: gromero at linux.vnet.ibm.com (Gustavo Romero)
Date: Thu, 5 Jan 2017 18:18:09 -0200
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <CA+3eh12aGxWsUbaMCK9B_7_a+cbzys944Qi2=UF4_A5X2-G02w@mail.gmail.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
<b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
<CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
<586DA958.3020104@linux.vnet.ibm.com>
<CA+3eh12aGxWsUbaMCK9B_7_a+cbzys944Qi2=UF4_A5X2-G02w@mail.gmail.com>
Message-ID: <586EAA01.8060207@linux.vnet.ibm.com>
Hi Volker,
Please see my comments inline.
On 05-01-2017 11:18, Volker Simonis wrote:
> Hi Gustavo,
>
> I finally got a Power machine which supports RTM.
Good :)
> So before pushing this change, I thought I run the RTM jtreg tests.
>
> Obviously your change improves the situation by preventing crashes
> because of RTMSpinLoopCount=0. But I still get 10 failures when
> running the RTM tests (test/compiler/rtm) on linux/ppc64:
Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But
after that the test is not passing yet. It looks like it is expecting fewer
abortions and I'm wondering if it's because on Power the transaction is aborted
if a signal is caught in the middle (the JVM uses signal quite frequently...),
thus an intrinsic property of the JVM on Power. I'll continue the investigation.
>
> compiler/rtm/locking/TestRTMAbortRatio.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Expected to get exit
> value of [0]
> compiler/rtm/locking/TestRTMAbortThreshold.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Expected that method with
> rtm lock elision was deoptimized after 1 lock attempts: expected 10000
> to equal 1
> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Two uncommon traps with
> reason rtm_state_change should be fired.: expected 0 to equal 2
> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Expected to get only one
> deoptimization due to rtm state change: expected 0 to equal 1
> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Expected to get only one
> deoptimization due to rtm state change: expected 0 to equal 1
> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: At least one
> deoptimization due to rtm_state_chage is expected: expected 0 > 0
> compiler/rtm/locking/TestRTMLockingThreshold.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: VM output should contain
> two RTM locking statistics entries.: expected 1 to equal 2
> compiler/rtm/locking/TestRTMRetryCount.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: It is expected to get 2
> aborts: expected 3 to equal 2
> compiler/rtm/locking/TestRTMSpinLoopCount.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: Total aborts count (2001)
> should be less or equal to 1001: expected that 2001 <= 1001
> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: VM output should contain
> exactly one rtm locking statistics entry for method
> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
> Failed. Execution failed: `main'
> threw exception: java.lang.RuntimeException: RTM locking statistics
> should contain non zero total aborts count: expected 0 > 0
>
> On the other hand, the situation on linux/x86_64 seems similar (with
> 7-9 failures depending on the run):
>
> compiler/rtm/locking/TestRTMAbortThreshold.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: Expected that
> method with rtm lock elision was deoptimized after 1 lock attempts:
> expected 10000 to equal 1
> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: Two uncommon traps
> with reason rtm_state_change should be fired.: expected 0 to equal 2
> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: Expected to get
> only one deoptimization due to rtm state change: expected 0 to equal 1
> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: After
> LockThreshold was reached, method should be recompiled with rtm lock
> eliding.: expected null to not equal null
> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: At least one
> deoptimization due to rtm_state_chage is expected: expected 0 > 0
> compiler/rtm/locking/TestRTMLockingThreshold.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: VM output should
> contain two RTM locking statistics entries.: expected 1 to equal 2
> compiler/rtm/locking/TestRTMTotalCountIncrRate.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: VM output should
> contain exactly one RTM locking statistics entry for method
> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
> to equal 1
> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: VM output should
> contain exactly one rtm locking statistics entry for method
> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
> Failed. Execution failed:
> `main' threw exception: java.lang.RuntimeException: RTM locking
> statistics should contain non zero total aborts count: expected 0 > 0
>
> Are these the same results you are seeing as well?
I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests
are failing as well, but fewer in comparison to Power. Much unfortunately I
don't know when I'll be able to have a x64 machine available again...
I've got the following tests status on a POWER8 machine:
FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java
FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java
FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java
FAILED: compiler/rtm/locking/TestRTMRetryCount.java
FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java
FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java
FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java
Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java
Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java
Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java
Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java
Passed: compiler/rtm/cli/TestRTMRetryCountOption.java
Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java
Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java
Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java
Passed: compiler/rtm/locking/TestRTMAbortRatio.java
Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java
Passed: compiler/rtm/locking/TestUseRTMDeopt.java
Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
Test results: passed: 28; failed: 10
Hence similar to what you've reported, except for TestRTMAbortRatio.java
which passed [1], although I would expect more aborts than what was
reported.
> The JDK 9 Early Access Build Test Results site at
> http://download.java.net/openjdk/testresults/9/testresults.html
> reports these tests as passed, but I think that may be because they
> run on hardware which doesn't support RTM?
Exactly. I discussed that briefly with David here [2] when fixing [3]
and I guess that's the reason for the regression 8171236 [4] not being
detected firstly at the Oracle side.
Regards,
Gustavo
[1] http://paste.fedoraproject.org/520455/83645916/raw/
[2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html
[3] https://bugs.openjdk.java.net/browse/JDK-8164987
[4] https://bugs.openjdk.java.net/browse/JDK-8171236
> @Vladimir, David: do you regularly run the RTM tests on linux/x86_64
> and do they really all pass in your environment? (I've tested with
> Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
> on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
> coreinfo.exe both support RTM).
>
> Thank you and best regards,
> Volker
>
> On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
> <gromero at linux.vnet.ibm.com> wrote:
>> Hi
>>
>> On 03-01-2017 16:08, Volker Simonis wrote:
>>> Hi David,
>>>
>>> thanks for looking at this change.
>>> As this is ppc64-only, I'll sponsor it.
>>>
>>> Regards,
>>> Volker
>>
>> David, thanks for reviewing the change.
>>
>> Volker, thanks for sponsoring it.
>>
>> Vladimir, thanks for setting the proper priority and fix version tag.
>>
>>
>> Regards,
>> Gustavo
>>
>>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>> Seems fine.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>>
>>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>>> since
>>>>> I understand that a formal review has to be submitted to the hs ML I
>>>>> resent it.
>>>>>
>>>>> Is any thing missing on my side?
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Gustavo
>>>>>
>>>>> [1]
>>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>>
>>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Could the following change be reviewed please?
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo
>>>>>>
>>>>>
>>>>
>>>
>>
>
From david.holmes at oracle.com Thu Jan 5 21:19:26 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jan 2017 07:19:26 +1000
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <12fa230b-4281-fb3b-7ea4-488075d31166@oracle.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
<12fa230b-4281-fb3b-7ea4-488075d31166@oracle.com>
Message-ID: <bf3518ac-83be-a197-e88e-f20b2a70e3f0@oracle.com>
Thanks George!
David
On 6/01/2017 12:27 AM, George Triantafillou wrote:
> Hi David,
>
> Looks good!
>
> -George
>
> On 1/4/2017 11:34 PM, David Holmes wrote:
>> Please review this backport of the fix for 8170888, it can't apply
>> cleanly due to use of unified logging, but that is the only change.
>>
>> Original JDK 9 review thread:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>
>> JDK 9 changeset:
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
>>
>> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
>>
>> Thanks,
>> David
>> -----
>
From david.holmes at oracle.com Thu Jan 5 21:19:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Jan 2017 07:19:40 +1000
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <E3A1A446-E7CB-432F-B0B1-A5CAFEA64A03@oracle.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
<E3A1A446-E7CB-432F-B0B1-A5CAFEA64A03@oracle.com>
Message-ID: <e814aff6-3465-6aa0-ffcf-0fe193edaeaa@oracle.com>
Thanks Karen!
David
On 6/01/2017 3:59 AM, Karen Kinnear wrote:
> David,
>
> Looks good!
>
> thanks,
> Karen
>
>> On Jan 4, 2017, at 11:34 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Please review this backport of the fix for 8170888, it can't apply cleanly due to use of unified logging, but that is the only change.
>>
>> Original JDK 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>
>> JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49
>>
>> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
>>
>> Thanks,
>> David
>> -----
>
From rwestrel at redhat.com Fri Jan 6 16:45:34 2017
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 06 Jan 2017 17:45:34 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
Message-ID: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
Membership in the hotspot Group.
Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
has been working on Hotspot for 3 years and contributed more than 50
changes.
Votes are due by Thu, January 20, 2017.
Only current Members of the hotspot Group [1] are eligible to vote on
this nomination. Votes must be cast in the open by replying to this
mailing list
For Lazy Consensus voting instructions, see [2].
Roland.
[1] http://openjdk.java.net/census#hotspot
[2] http://openjdk.java.net/groups/#member-vote
From rwestrel at redhat.com Fri Jan 6 16:46:41 2017
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 06 Jan 2017 17:46:41 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <dk660ls9lvy.fsf@rwestrel.remote.csb>
Vote: yes
Roland Westrelin <rwestrel at redhat.com> writes:
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
From ChrisPhi at LGonQn.Org Fri Jan 6 17:55:50 2017
From: ChrisPhi at LGonQn.Org (Chris Phillips @ T O)
Date: Fri, 06 Jan 2017 12:55:50 -0500
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk660ls9lvy.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
<dk660ls9lvy.fsf@rwestrel.remote.csb>
Message-ID: <586FDA26.60800@LGonQn.Org>
Vote: yes
ChrisPhi
From david.holmes at oracle.com Fri Jan 6 22:12:51 2017
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 7 Jan 2017 08:12:51 +1000
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <bbe01fc3-282a-a0ea-e729-9f38e771531e@oracle.com>
Vote: yes
David
On 7/01/2017 2:45 AM, Roland Westrelin wrote:
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
>
From devnexen at gmail.com Fri Jan 6 22:23:28 2017
From: devnexen at gmail.com (David CARLIER)
Date: Fri, 6 Jan 2017 22:23:28 +0000
Subject: Hotspot for BSD / opinion request
In-Reply-To: <ef2ebc7c-4958-bab1-ced8-9b5baed49824@oracle.com>
References: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
<1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>
<ef2ebc7c-4958-bab1-ced8-9b5baed49824@oracle.com>
Message-ID: <CA+XhMqzSj3qBCi14Vxh_V9A1Be8K5zChjvNGaTwoag7i4rAARg@mail.gmail.com>
Thanks, here a patch proposal. Kindest regards.
On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com> wrote:
> If there is a platform, we support, where the default settings are
> inappropriate then setting them explicitly would be the right thing to do.
>
> David
>
>
> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>
>> Hi,
>>
>> Forwarding to mailing lists since I can't answer.
>> May be someone can answer your question on these lists.
>>
>> Regards,
>> Vladimir
>>
>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>
>>> Hi,
>>>
>>> this is my first mail to the maiing list, I have difficulties to push
>>> messages to any mailing lists, but as BSD user/dev I was
>>> looking at code's part like this one
>>>
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>
>>>
>>> I was wondering if it would be better to explicitally set the attr
>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>
>>> What do you think ?
>>>
>>> Thanks in advance.
>>>
>>> Kindest regards.
>>>
>
From haozhun.jin at gmail.com Sat Jan 7 02:23:20 2017
From: haozhun.jin at gmail.com (Haozhun Jin)
Date: Fri, 6 Jan 2017 18:23:20 -0800
Subject: Understanding "too many recompiles"
Message-ID: <CAL1rBeKmR22QHU-PjhGq4KNQ61wB2US5M40WVK7XQ_T_bqq5jw@mail.gmail.com>
I am hitting "too many recompilation" (i.e. PerMethodRecompilationCutoff)
in a
production cluster for a distributed parallel Java application, usually
after
running for a week or more. It sometimes causes deoptimization storm (which
I
asked about in an email a few months ago). This email is not about
deoptimization stroms. Even if deoptimization storm is not triggered,
interpret
will mean very bad performance. Therefore, we don't want the cutoff hit.
My understanding of JVM is rather primitive. Therefore, I would like
opinions
from you to see whether my guesses are plausible.
I tried to reproduce it with some toy code. My toy code has a lot of
branches.
I make it take the first branch for a million iterations, and then take the
second branch for millions time, and then the third branch, the forth
branch,
etc. After all branch were taken, I'll have it start all over (repeatedly).
While our production workload is not as artificial, something similar could
happen. I was hoping that this will be able to trick JVM into doing a
recompilations for as many times as the number of branches multiplied by the
number of times it is started all over. As long as I continue running this
program, this would result in an unbounded number of recompilations.
It turns out JVM is smarter than this. I observe that JVM is smart enough to
compile in the first branch at the beginning, the first two after a while,
...,
and then all branches eventually. At that point, it stops recompiling. As a
result, the test code I wrote can't really trick JVM into doing an unbounded
number of recompilations. It will recompile as many times as the number of
branches I have.
A few things that happen in my production clusters that my toy code didn't
mimic:
* The production cluster generates bytecode on the fly. For each shape of
input, we generate new bytecode and load it into a new class.
* If the same shape of input comes again, we'll reuse the method generated
previously. This could be a few hours or even a day since the code was
used
last time. For the few hours or a day in between, the method did not run
at
all.
Now, I have a naive guess:
* Maybe, after a long time, JVM throws out old stats (i.e. forget that some
branches were taken). As a result, every time the method runs again (after
not running for a while), it will recompile with some branches left out,
and
then recompile a few times to put them back in. If this happens a few
dozen
times, it eventually hits the PerMethodRecompilationCutoff.
Is this plausible? If the answer to my question is yes,
* Can you elaborate a little bit and tell me when and under what
circumstance
will this happen? A pointer to some reading will be great. I would still
like to reproduce this in a toy program if possible.
* Does it mean I should simply increase -XX:PerMethodRecompilationCutoff by
10X, and consider the problem solved? Will I get really bad side effects.
Alternatively, I could also impose an expiration time on these generated
methods. After all, the cost of generation, class loading, initial
interpretation/optimization is likely neglible if a method is only used
once
every hour.
Thank you
Haozhun
From volker.simonis at gmail.com Sat Jan 7 10:31:09 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Sat, 7 Jan 2017 11:31:09 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <CA+3eh11uLhGgVh_pL5wy1m_UGSjkR=BtaMVO5DzOkd6-+-KB=g@mail.gmail.com>
Vote: yes
On Fri, Jan 6, 2017 at 5:45 PM, Roland Westrelin <rwestrel at redhat.com> wrote:
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
From goetz.lindenmaier at sap.com Mon Jan 9 07:37:09 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Jan 2017 07:37:09 +0000
Subject: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <5f53ea29de3242c389ae618ceaa3e90c@DEROTE13DE08.global.corp.sap>
Vote: yes
Goetz
> -----Original Message-----
> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
> Behalf Of Roland Westrelin
> Sent: Freitag, 6. Januar 2017 18:46
> To: hotspot-dev at openjdk.java.net
> Subject: CFV: New hotspot Group Member: Aleksey Shipilev
>
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
From thomas.schatzl at oracle.com Mon Jan 9 09:13:27 2017
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 09 Jan 2017 10:13:27 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <1483953207.7068.12.camel@oracle.com>
Vote: yes
Thanks,
? Thomas
On Fri, 2017-01-06 at 17:45 +0100, Roland Westrelin wrote:
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK
> 8u.??He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
From vladimir.kozlov at oracle.com Mon Jan 9 09:34:05 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Jan 2017 01:34:05 -0800
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <5939c52a-842c-6722-1afd-3ebc4b430bf2@oracle.com>
Vote: yes
On 1/6/17 8:45 AM, Roland Westrelin wrote:
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
>
From mikael.gerdin at oracle.com Mon Jan 9 09:39:14 2017
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Mon, 9 Jan 2017 10:39:14 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <edd67981-84b1-99df-1b4b-58d8c35082f7@oracle.com>
Vote: yes
/Mikael
On 2017-01-06 17:45, Roland Westrelin wrote:
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
>
From tobias.hartmann at oracle.com Mon Jan 9 10:11:51 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 9 Jan 2017 11:11:51 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <587361E7.3040702@oracle.com>
Vote: yes
On 06.01.2017 17:45, Roland Westrelin wrote:
>
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
>
From zoltan.majo at oracle.com Mon Jan 9 14:22:05 2017
From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=)
Date: Mon, 9 Jan 2017 15:22:05 +0100
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <0ffe7b2c-da42-ad51-4639-e26b748b8f8f@oracle.com>
Vote: yes.
Best regards,
Zoltan
On 01/06/2017 05:45 PM, Roland Westrelin wrote:
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
From daniel.daugherty at oracle.com Mon Jan 9 16:48:21 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 9 Jan 2017 09:48:21 -0700
Subject: Hotspot for BSD / opinion request
In-Reply-To: <CA+XhMqzSj3qBCi14Vxh_V9A1Be8K5zChjvNGaTwoag7i4rAARg@mail.gmail.com>
References: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
<1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>
<ef2ebc7c-4958-bab1-ced8-9b5baed49824@oracle.com>
<CA+XhMqzSj3qBCi14Vxh_V9A1Be8K5zChjvNGaTwoag7i4rAARg@mail.gmail.com>
Message-ID: <3c580abc-9333-8803-abc1-1b0863123060@oracle.com>
David C.,
If you sent the patch as an attachment, then you should be advised that
the OpenJDK email servers strip attachments. If the patch is relatively
small, then you can send it in-line...
Dan
On 1/6/17 3:23 PM, David CARLIER wrote:
> Thanks, here a patch proposal. Kindest regards.
>
> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com> wrote:
>> If there is a platform, we support, where the default settings are
>> inappropriate then setting them explicitly would be the right thing to do.
>>
>> David
>>
>>
>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>> Hi,
>>>
>>> Forwarding to mailing lists since I can't answer.
>>> May be someone can answer your question on these lists.
>>>
>>> Regards,
>>> Vladimir
>>>
>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>> Hi,
>>>>
>>>> this is my first mail to the maiing list, I have difficulties to push
>>>> messages to any mailing lists, but as BSD user/dev I was
>>>> looking at code's part like this one
>>>>
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>
>>>>
>>>> I was wondering if it would be better to explicitally set the attr
>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>
>>>> What do you think ?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Kindest regards.
>>>>
From devnexen at gmail.com Mon Jan 9 17:37:47 2017
From: devnexen at gmail.com (David CARLIER)
Date: Mon, 9 Jan 2017 17:37:47 +0000
Subject: Hotspot for BSD / opinion request
In-Reply-To: <3c580abc-9333-8803-abc1-1b0863123060@oracle.com>
References: <CA+XhMqy0L=6DHzHmFFJQWgn5VYXpv4EV6OHOdKCJ3iTah8RHSQ@mail.gmail.com>
<1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com>
<ef2ebc7c-4958-bab1-ced8-9b5baed49824@oracle.com>
<CA+XhMqzSj3qBCi14Vxh_V9A1Be8K5zChjvNGaTwoag7i4rAARg@mail.gmail.com>
<3c580abc-9333-8803-abc1-1b0863123060@oracle.com>
Message-ID: <CA+XhMqz1L2NXCsYikwt4d89i9zLDBJDNW2O6BW5339SJpSHVQQ@mail.gmail.com>
Hi sure thing
diff --git a/src/os/bsd/vm/os_bsd.hpp b/src/os/bsd/vm/os_bsd.hpp
--- a/src/os/bsd/vm/os_bsd.hpp
+++ b/src/os/bsd/vm/os_bsd.hpp
@@ -175,6 +175,7 @@
volatile int _Event;
volatile int _nParked;
pthread_mutex_t _mutex[1];
+ pthread_mutexattr_t _attr[1];
pthread_cond_t _cond[1];
double PostPad[2];
Thread * _Assoc;
@@ -187,7 +188,11 @@
int status;
status = pthread_cond_init(_cond, NULL);
assert_status(status == 0, status, "cond_init");
- status = pthread_mutex_init(_mutex, NULL);
+ status = pthread_mutexattr_init(_attr);
+ assert_status(status == 0, status, "attr_init");
+ status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
+ assert_status(status == 0, status, "attr_settype");
+ status = pthread_mutex_init(_mutex, _attr);
assert_status(status == 0, status, "mutex_init");
_Event = 0;
_nParked = 0;
@@ -206,6 +211,7 @@
class PlatformParker : public CHeapObj<mtInternal> {
protected:
pthread_mutex_t _mutex[1];
+ pthread_mutexattr_t _attr[1];
pthread_cond_t _cond[1];
public: // TODO-FIXME: make dtor private
@@ -216,7 +222,11 @@
int status;
status = pthread_cond_init(_cond, NULL);
assert_status(status == 0, status, "cond_init");
- status = pthread_mutex_init(_mutex, NULL);
+ status = pthread_mutexattr_init(_attr);
+ assert_status(status == 0, status, "attr_init");
+ status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
+ assert_status(status == 0, status, "attr_settype");
+ status = pthread_mutex_init(_mutex, _attr);
assert_status(status == 0, status, "mutex_init");
}
};
Kind regards.
Thanks.
On 9 January 2017 at 16:48, Daniel D. Daugherty
<daniel.daugherty at oracle.com> wrote:
> David C.,
>
> If you sent the patch as an attachment, then you should be advised that
> the OpenJDK email servers strip attachments. If the patch is relatively
> small, then you can send it in-line...
>
> Dan
>
>
>
> On 1/6/17 3:23 PM, David CARLIER wrote:
>>
>> Thanks, here a patch proposal. Kindest regards.
>>
>> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com>
>> wrote:
>>>
>>> If there is a platform, we support, where the default settings are
>>> inappropriate then setting them explicitly would be the right thing to
>>> do.
>>>
>>> David
>>>
>>>
>>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>>>
>>>> Hi,
>>>>
>>>> Forwarding to mailing lists since I can't answer.
>>>> May be someone can answer your question on these lists.
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> this is my first mail to the maiing list, I have difficulties to push
>>>>> messages to any mailing lists, but as BSD user/dev I was
>>>>> looking at code's part like this one
>>>>>
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>>
>>>>>
>>>>> I was wondering if it would be better to explicitally set the attr
>>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Kindest regards.
>>>>>
>
From daniel.daugherty at oracle.com Mon Jan 9 18:14:19 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 9 Jan 2017 11:14:19 -0700
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <9cc7da90-ee6f-44d4-6976-4dfee73f4001@oracle.com>
Vote: yes
Dan
On 1/6/17 9:45 AM, Roland Westrelin wrote:
> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
> Membership in the hotspot Group.
>
> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
> has been working on Hotspot for 3 years and contributed more than 50
> changes.
>
> Votes are due by Thu, January 20, 2017.
>
> Only current Members of the hotspot Group [1] are eligible to vote on
> this nomination. Votes must be cast in the open by replying to this
> mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Roland.
>
> [1] http://openjdk.java.net/census#hotspot
> [2] http://openjdk.java.net/groups/#member-vote
>
From vladimir.kozlov at oracle.com Tue Jan 10 01:02:58 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 9 Jan 2017 17:02:58 -0800
Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0
In-Reply-To: <586EAA01.8060207@linux.vnet.ibm.com>
References: <58530522.3030102@linux.vnet.ibm.com>
<58666849.1020700@linux.vnet.ibm.com>
<b180ec75-3a7e-8a3f-9f9e-b3e425f308a8@oracle.com>
<CA+3eh13u2JnokMGWLvfBqUZjmWpFk0=xmu3--Se4W=tG3PQz0Q@mail.gmail.com>
<586DA958.3020104@linux.vnet.ibm.com>
<CA+3eh12aGxWsUbaMCK9B_7_a+cbzys944Qi2=UF4_A5X2-G02w@mail.gmail.com>
<586EAA01.8060207@linux.vnet.ibm.com>
Message-ID: <5df0a239-d242-5853-0f47-2fd2e6d8afcb@oracle.com>
I looked on linux test machines we run and they don't RTM :(
Or few machines with RTM are not used to run these particular tests.
Vladimir
On 1/5/17 12:18 PM, Gustavo Romero wrote:
> Hi Volker,
>
> Please see my comments inline.
>
> On 05-01-2017 11:18, Volker Simonis wrote:
>> Hi Gustavo,
>>
>> I finally got a Power machine which supports RTM.
>
> Good :)
>
>
>> So before pushing this change, I thought I run the RTM jtreg tests.
>>
>> Obviously your change improves the situation by preventing crashes
>> because of RTMSpinLoopCount=0. But I still get 10 failures when
>> running the RTM tests (test/compiler/rtm) on linux/ppc64:
>
> Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But
> after that the test is not passing yet. It looks like it is expecting fewer
> abortions and I'm wondering if it's because on Power the transaction is aborted
> if a signal is caught in the middle (the JVM uses signal quite frequently...),
> thus an intrinsic property of the JVM on Power. I'll continue the investigation.
>
>
>>
>> compiler/rtm/locking/TestRTMAbortRatio.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Expected to get exit
>> value of [0]
>> compiler/rtm/locking/TestRTMAbortThreshold.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Expected that method with
>> rtm lock elision was deoptimized after 1 lock attempts: expected 10000
>> to equal 1
>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Two uncommon traps with
>> reason rtm_state_change should be fired.: expected 0 to equal 2
>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Expected to get only one
>> deoptimization due to rtm state change: expected 0 to equal 1
>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Expected to get only one
>> deoptimization due to rtm state change: expected 0 to equal 1
>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: At least one
>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>> compiler/rtm/locking/TestRTMLockingThreshold.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: VM output should contain
>> two RTM locking statistics entries.: expected 1 to equal 2
>> compiler/rtm/locking/TestRTMRetryCount.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: It is expected to get 2
>> aborts: expected 3 to equal 2
>> compiler/rtm/locking/TestRTMSpinLoopCount.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: Total aborts count (2001)
>> should be less or equal to 1001: expected that 2001 <= 1001
>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: VM output should contain
>> exactly one rtm locking statistics entry for method
>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>> Failed. Execution failed: `main'
>> threw exception: java.lang.RuntimeException: RTM locking statistics
>> should contain non zero total aborts count: expected 0 > 0
>>
>> On the other hand, the situation on linux/x86_64 seems similar (with
>> 7-9 failures depending on the run):
>>
>> compiler/rtm/locking/TestRTMAbortThreshold.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: Expected that
>> method with rtm lock elision was deoptimized after 1 lock attempts:
>> expected 10000 to equal 1
>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: Two uncommon traps
>> with reason rtm_state_change should be fired.: expected 0 to equal 2
>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: Expected to get
>> only one deoptimization due to rtm state change: expected 0 to equal 1
>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: After
>> LockThreshold was reached, method should be recompiled with rtm lock
>> eliding.: expected null to not equal null
>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: At least one
>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>> compiler/rtm/locking/TestRTMLockingThreshold.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: VM output should
>> contain two RTM locking statistics entries.: expected 1 to equal 2
>> compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: VM output should
>> contain exactly one RTM locking statistics entry for method
>> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
>> to equal 1
>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: VM output should
>> contain exactly one rtm locking statistics entry for method
>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>> Failed. Execution failed:
>> `main' threw exception: java.lang.RuntimeException: RTM locking
>> statistics should contain non zero total aborts count: expected 0 > 0
>>
>> Are these the same results you are seeing as well?
>
> I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests
> are failing as well, but fewer in comparison to Power. Much unfortunately I
> don't know when I'll be able to have a x64 machine available again...
>
> I've got the following tests status on a POWER8 machine:
>
> FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java
> FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
> FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
> FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
> FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java
> FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java
> FAILED: compiler/rtm/locking/TestRTMRetryCount.java
> FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java
> FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java
> FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java
> Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java
> Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java
> Passed: compiler/rtm/cli/TestRTMRetryCountOption.java
> Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java
> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
> Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java
> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
> Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java
> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
> Test results: passed: 28; failed: 10
>
> Hence similar to what you've reported, except for TestRTMAbortRatio.java
> which passed [1], although I would expect more aborts than what was
> reported.
>
>
>> The JDK 9 Early Access Build Test Results site at
>> http://download.java.net/openjdk/testresults/9/testresults.html
>> reports these tests as passed, but I think that may be because they
>> run on hardware which doesn't support RTM?
>
> Exactly. I discussed that briefly with David here [2] when fixing [3]
> and I guess that's the reason for the regression 8171236 [4] not being
> detected firstly at the Oracle side.
>
>
> Regards,
> Gustavo
>
> [1] http://paste.fedoraproject.org/520455/83645916/raw/
> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8164987
> [4] https://bugs.openjdk.java.net/browse/JDK-8171236
>
>
>> @Vladimir, David: do you regularly run the RTM tests on linux/x86_64
>> and do they really all pass in your environment? (I've tested with
>> Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
>> on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
>> coreinfo.exe both support RTM).
>>
>> Thank you and best regards,
>> Volker
>>
>> On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
>> <gromero at linux.vnet.ibm.com> wrote:
>>> Hi
>>>
>>> On 03-01-2017 16:08, Volker Simonis wrote:
>>>> Hi David,
>>>>
>>>> thanks for looking at this change.
>>>> As this is ppc64-only, I'll sponsor it.
>>>>
>>>> Regards,
>>>> Volker
>>>
>>> David, thanks for reviewing the change.
>>>
>>> Volker, thanks for sponsoring it.
>>>
>>> Vladimir, thanks for setting the proper priority and fix version tag.
>>>
>>>
>>> Regards,
>>> Gustavo
>>>
>>>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>> Seems fine.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>
>>>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>>>> since
>>>>>> I understand that a formal review has to be submitted to the hs ML I
>>>>>> resent it.
>>>>>>
>>>>>> Is any thing missing on my side?
>>>>>>
>>>>>> Thank you.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo
>>>>>>
>>>>>> [1]
>>>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>>>
>>>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Could the following change be reviewed please?
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gustavo
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
From asim2025 at yahoo.com Tue Jan 10 01:07:06 2017
From: asim2025 at yahoo.com (Asim Aslam)
Date: Mon, 9 Jan 2017 20:07:06 -0500
Subject: hotspot-dev Digest, Vol 117, Issue 7
In-Reply-To: <mailman.3411.1484010187.12703.hotspot-dev@openjdk.java.net>
References: <mailman.3411.1484010187.12703.hotspot-dev@openjdk.java.net>
Message-ID: <1F9347E8-3926-4E76-A763-A7D8CB281E1A@yahoo.com>
> On Jan 9, 2017, at 8:03 PM, hotspot-dev-request at openjdk.java.net wrote:
>
> Send hotspot-dev mailing list submissions to
> hotspot-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-dev
> or, via email, send a message with subject or body 'help' to
> hotspot-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
> hotspot-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Vladimir Kozlov)
> 2. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Mikael Gerdin)
> 3. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Tobias Hartmann)
> 4. Re: CFV: New hotspot Group Member: Aleksey Shipilev (Zolt?n Maj?)
> 5. Re: Hotspot for BSD / opinion request (Daniel D. Daugherty)
> 6. Re: Hotspot for BSD / opinion request (David CARLIER)
> 7. Re: CFV: New hotspot Group Member: Aleksey Shipilev
> (Daniel D. Daugherty)
> 8. Re: RFR(S): 8171266: PPC64: Add support to
> -XX:RTMSpinLoopCount=0 (Vladimir Kozlov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 9 Jan 2017 01:34:05 -0800
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <5939c52a-842c-6722-1afd-3ebc4b430bf2 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
>> On 1/6/17 8:45 AM, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Jan 2017 10:39:14 +0100
> From: Mikael Gerdin <mikael.gerdin at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <edd67981-84b1-99df-1b4b-58d8c35082f7 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
> /Mikael
>
>> On 2017-01-06 17:45, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 9 Jan 2017 11:11:51 +0100
> From: Tobias Hartmann <tobias.hartmann at oracle.com>
> To: Roland Westrelin <rwestrel at redhat.com>,
> hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <587361E7.3040702 at oracle.com>
> Content-Type: text/plain; charset=windows-1252
>
> Vote: yes
>
>> On 06.01.2017 17:45, Roland Westrelin wrote:
>>
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 9 Jan 2017 15:22:05 +0100
> From: Zolt?n Maj? <zoltan.majo at oracle.com>
> To: Roland Westrelin <rwestrel at redhat.com>,
> hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <0ffe7b2c-da42-ad51-4639-e26b748b8f8f at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes.
>
> Best regards,
>
>
> Zoltan
>
>> On 01/06/2017 05:45 PM, Roland Westrelin wrote:
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 9 Jan 2017 09:48:21 -0700
> From: "Daniel D. Daugherty" <daniel.daugherty at oracle.com>
> To: David CARLIER <devnexen at gmail.com>, David Holmes
> <david.holmes at oracle.com>
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, hotspot-dev Source Developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: Hotspot for BSD / opinion request
> Message-ID: <3c580abc-9333-8803-abc1-1b0863123060 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> David C.,
>
> If you sent the patch as an attachment, then you should be advised that
> the OpenJDK email servers strip attachments. If the patch is relatively
> small, then you can send it in-line...
>
> Dan
>
>
>> On 1/6/17 3:23 PM, David CARLIER wrote:
>> Thanks, here a patch proposal. Kindest regards.
>>
>>> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com> wrote:
>>> If there is a platform, we support, where the default settings are
>>> inappropriate then setting them explicitly would be the right thing to do.
>>>
>>> David
>>>
>>>
>>>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>>> Hi,
>>>>
>>>> Forwarding to mailing lists since I can't answer.
>>>> May be someone can answer your question on these lists.
>>>>
>>>> Regards,
>>>> Vladimir
>>>>
>>>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>>> Hi,
>>>>>
>>>>> this is my first mail to the maiing list, I have difficulties to push
>>>>> messages to any mailing lists, but as BSD user/dev I was
>>>>> looking at code's part like this one
>>>>>
>>>>>
>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>>
>>>>>
>>>>> I was wondering if it would be better to explicitally set the attr
>>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>>
>>>>> What do you think ?
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Kindest regards.
>>>>>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 9 Jan 2017 17:37:47 +0000
> From: David CARLIER <devnexen at gmail.com>
> To: daniel.daugherty at oracle.com
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, hotspot-dev Source Developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: Hotspot for BSD / opinion request
> Message-ID:
> <CA+XhMqz1L2NXCsYikwt4d89i9zLDBJDNW2O6BW5339SJpSHVQQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi sure thing
>
> diff --git a/src/os/bsd/vm/os_bsd.hpp b/src/os/bsd/vm/os_bsd.hpp
> --- a/src/os/bsd/vm/os_bsd.hpp
> +++ b/src/os/bsd/vm/os_bsd.hpp
> @@ -175,6 +175,7 @@
> volatile int _Event;
> volatile int _nParked;
> pthread_mutex_t _mutex[1];
> + pthread_mutexattr_t _attr[1];
> pthread_cond_t _cond[1];
> double PostPad[2];
> Thread * _Assoc;
> @@ -187,7 +188,11 @@
> int status;
> status = pthread_cond_init(_cond, NULL);
> assert_status(status == 0, status, "cond_init");
> - status = pthread_mutex_init(_mutex, NULL);
> + status = pthread_mutexattr_init(_attr);
> + assert_status(status == 0, status, "attr_init");
> + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
> + assert_status(status == 0, status, "attr_settype");
> + status = pthread_mutex_init(_mutex, _attr);
> assert_status(status == 0, status, "mutex_init");
> _Event = 0;
> _nParked = 0;
> @@ -206,6 +211,7 @@
> class PlatformParker : public CHeapObj<mtInternal> {
> protected:
> pthread_mutex_t _mutex[1];
> + pthread_mutexattr_t _attr[1];
> pthread_cond_t _cond[1];
>
> public: // TODO-FIXME: make dtor private
> @@ -216,7 +222,11 @@
> int status;
> status = pthread_cond_init(_cond, NULL);
> assert_status(status == 0, status, "cond_init");
> - status = pthread_mutex_init(_mutex, NULL);
> + status = pthread_mutexattr_init(_attr);
> + assert_status(status == 0, status, "attr_init");
> + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL);
> + assert_status(status == 0, status, "attr_settype");
> + status = pthread_mutex_init(_mutex, _attr);
> assert_status(status == 0, status, "mutex_init");
> }
> };
>
>
>
> Kind regards.
>
> Thanks.
>
> On 9 January 2017 at 16:48, Daniel D. Daugherty
> <daniel.daugherty at oracle.com> wrote:
>> David C.,
>>
>> If you sent the patch as an attachment, then you should be advised that
>> the OpenJDK email servers strip attachments. If the patch is relatively
>> small, then you can send it in-line...
>>
>> Dan
>>
>>
>>
>>> On 1/6/17 3:23 PM, David CARLIER wrote:
>>>
>>> Thanks, here a patch proposal. Kindest regards.
>>>
>>> On 24 December 2016 at 02:16, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>>
>>>> If there is a platform, we support, where the default settings are
>>>> inappropriate then setting them explicitly would be the right thing to
>>>> do.
>>>>
>>>> David
>>>>
>>>>
>>>>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Forwarding to mailing lists since I can't answer.
>>>>> May be someone can answer your question on these lists.
>>>>>
>>>>> Regards,
>>>>> Vladimir
>>>>>
>>>>>> On 12/23/16 2:17 AM, David CARLIER wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> this is my first mail to the maiing list, I have difficulties to push
>>>>>> messages to any mailing lists, but as BSD user/dev I was
>>>>>> looking at code's part like this one
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp
>>>>>>
>>>>>>
>>>>>> I was wondering if it would be better to explicitally set the attr
>>>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux
>>>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default).
>>>>>>
>>>>>> What do you think ?
>>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Kindest regards.
>>>>>>
>>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 9 Jan 2017 11:14:19 -0700
> From: "Daniel D. Daugherty" <daniel.daugherty at oracle.com>
> To: hotspot-dev at openjdk.java.net
> Subject: Re: CFV: New hotspot Group Member: Aleksey Shipilev
> Message-ID: <9cc7da90-ee6f-44d4-6976-4dfee73f4001 at oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Vote: yes
>
> Dan
>
>
>> On 1/6/17 9:45 AM, Roland Westrelin wrote:
>> I hereby nominate Aleksey Shipilev (OpenJDK user name: shade) to
>> Membership in the hotspot Group.
>>
>> Aleksey is a Reviewer in the JDK 9 Project and Committer in JDK 8u. He
>> has been working on Hotspot for 3 years and contributed more than 50
>> changes.
>>
>> Votes are due by Thu, January 20, 2017.
>>
>> Only current Members of the hotspot Group [1] are eligible to vote on
>> this nomination. Votes must be cast in the open by replying to this
>> mailing list
>>
>> For Lazy Consensus voting instructions, see [2].
>>
>> Roland.
>>
>> [1] http://openjdk.java.net/census#hotspot
>> [2] http://openjdk.java.net/groups/#member-vote
>>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 9 Jan 2017 17:02:58 -0800
> From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
> To: Gustavo Romero <gromero at linux.vnet.ibm.com>, Volker Simonis
> <volker.simonis at gmail.com>
> Cc: "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>, "hotspot-dev at openjdk.java.net"
> <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR(S): 8171266: PPC64: Add support to
> -XX:RTMSpinLoopCount=0
> Message-ID: <5df0a239-d242-5853-0f47-2fd2e6d8afcb at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I looked on linux test machines we run and they don't RTM :(
>
> Or few machines with RTM are not used to run these particular tests.
>
> Vladimir
>
>> On 1/5/17 12:18 PM, Gustavo Romero wrote:
>> Hi Volker,
>>
>> Please see my comments inline.
>>
>>> On 05-01-2017 11:18, Volker Simonis wrote:
>>> Hi Gustavo,
>>>
>>> I finally got a Power machine which supports RTM.
>>
>> Good :)
>>
>>
>>> So before pushing this change, I thought I run the RTM jtreg tests.
>>>
>>> Obviously your change improves the situation by preventing crashes
>>> because of RTMSpinLoopCount=0. But I still get 10 failures when
>>> running the RTM tests (test/compiler/rtm) on linux/ppc64:
>>
>> Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But
>> after that the test is not passing yet. It looks like it is expecting fewer
>> abortions and I'm wondering if it's because on Power the transaction is aborted
>> if a signal is caught in the middle (the JVM uses signal quite frequently...),
>> thus an intrinsic property of the JVM on Power. I'll continue the investigation.
>>
>>
>>>
>>> compiler/rtm/locking/TestRTMAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get exit
>>> value of [0]
>>> compiler/rtm/locking/TestRTMAbortThreshold.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected that method with
>>> rtm lock elision was deoptimized after 1 lock attempts: expected 10000
>>> to equal 1
>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Two uncommon traps with
>>> reason rtm_state_change should be fired.: expected 0 to equal 2
>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get only one
>>> deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Expected to get only one
>>> deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: At least one
>>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>>> compiler/rtm/locking/TestRTMLockingThreshold.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: VM output should contain
>>> two RTM locking statistics entries.: expected 1 to equal 2
>>> compiler/rtm/locking/TestRTMRetryCount.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: It is expected to get 2
>>> aborts: expected 3 to equal 2
>>> compiler/rtm/locking/TestRTMSpinLoopCount.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: Total aborts count (2001)
>>> should be less or equal to 1001: expected that 2001 <= 1001
>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: VM output should contain
>>> exactly one rtm locking statistics entry for method
>>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>>> Failed. Execution failed: `main'
>>> threw exception: java.lang.RuntimeException: RTM locking statistics
>>> should contain non zero total aborts count: expected 0 > 0
>>>
>>> On the other hand, the situation on linux/x86_64 seems similar (with
>>> 7-9 failures depending on the run):
>>>
>>> compiler/rtm/locking/TestRTMAbortThreshold.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Expected that
>>> method with rtm lock elision was deoptimized after 1 lock attempts:
>>> expected 10000 to equal 1
>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Two uncommon traps
>>> with reason rtm_state_change should be fired.: expected 0 to equal 2
>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: Expected to get
>>> only one deoptimization due to rtm state change: expected 0 to equal 1
>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: After
>>> LockThreshold was reached, method should be recompiled with rtm lock
>>> eliding.: expected null to not equal null
>>> compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: At least one
>>> deoptimization due to rtm_state_chage is expected: expected 0 > 0
>>> compiler/rtm/locking/TestRTMLockingThreshold.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain two RTM locking statistics entries.: expected 1 to equal 2
>>> compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain exactly one RTM locking statistics entry for method
>>> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0
>>> to equal 1
>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: VM output should
>>> contain exactly one rtm locking statistics entry for method
>>> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1
>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>>> Failed. Execution failed:
>>> `main' threw exception: java.lang.RuntimeException: RTM locking
>>> statistics should contain non zero total aborts count: expected 0 > 0
>>>
>>> Are these the same results you are seeing as well?
>>
>> I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests
>> are failing as well, but fewer in comparison to Power. Much unfortunately I
>> don't know when I'll be able to have a x64 machine available again...
>>
>> I've got the following tests status on a POWER8 machine:
>>
>> FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java
>> FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java
>> FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java
>> FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java
>> FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java
>> FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java
>> FAILED: compiler/rtm/locking/TestRTMRetryCount.java
>> FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java
>> FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java
>> FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java
>> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java
>> Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java
>> Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java
>> Passed: compiler/rtm/cli/TestRTMRetryCountOption.java
>> Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java
>> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java
>> Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java
>> Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java
>> Passed: compiler/rtm/locking/TestRTMAbortRatio.java
>> Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java
>> Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java
>> Passed: compiler/rtm/locking/TestUseRTMDeopt.java
>> Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java
>> Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java
>> Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java
>> Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java
>> Test results: passed: 28; failed: 10
>>
>> Hence similar to what you've reported, except for TestRTMAbortRatio.java
>> which passed [1], although I would expect more aborts than what was
>> reported.
>>
>>
>>> The JDK 9 Early Access Build Test Results site at
>>> http://download.java.net/openjdk/testresults/9/testresults.html
>>> reports these tests as passed, but I think that may be because they
>>> run on hardware which doesn't support RTM?
>>
>> Exactly. I discussed that briefly with David here [2] when fixing [3]
>> and I guess that's the reason for the regression 8171236 [4] not being
>> detected firstly at the Oracle side.
>>
>>
>> Regards,
>> Gustavo
>>
>> [1] http://paste.fedoraproject.org/520455/83645916/raw/
>> [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8164987
>> [4] https://bugs.openjdk.java.net/browse/JDK-8171236
>>
>>
>>> @Vladimir, David: do you regularly run the RTM tests on linux/x86_64
>>> and do they really all pass in your environment? (I've tested with
>>> Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7
>>> on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and
>>> coreinfo.exe both support RTM).
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero
>>> <gromero at linux.vnet.ibm.com> wrote:
>>>> Hi
>>>>
>>>>> On 03-01-2017 16:08, Volker Simonis wrote:
>>>>> Hi David,
>>>>>
>>>>> thanks for looking at this change.
>>>>> As this is ppc64-only, I'll sponsor it.
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>
>>>> David, thanks for reviewing the change.
>>>>
>>>> Volker, thanks for sponsoring it.
>>>>
>>>> Vladimir, thanks for setting the proper priority and fix version tag.
>>>>
>>>>
>>>> Regards,
>>>> Gustavo
>>>>
>>>>>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>>> Seems fine.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>
>>>>>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but
>>>>>>> since
>>>>>>> I understand that a formal review has to be submitted to the hs ML I
>>>>>>> resent it.
>>>>>>>
>>>>>>> Is any thing missing on my side?
>>>>>>>
>>>>>>> Thank you.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gustavo
>>>>>>>
>>>>>>> [1]
>>>>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html
>>>>>>>
>>>>>>>> On 15-12-2016 19:03, Gustavo Romero wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Could the following change be reviewed please?
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/
>>>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Gustavo
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> End of hotspot-dev Digest, Vol 117, Issue 7
> *******************************************
From yumin.qi at gmail.com Tue Jan 10 19:45:01 2017
From: yumin.qi at gmail.com (yumin qi)
Date: Tue, 10 Jan 2017 11:45:01 -0800
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <e814aff6-3465-6aa0-ffcf-0fe193edaeaa@oracle.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
<E3A1A446-E7CB-432F-B0B1-A5CAFEA64A03@oracle.com>
<e814aff6-3465-6aa0-ffcf-0fe193edaeaa@oracle.com>
Message-ID: <CAOEheN5s2L6gqFvHGXfPi=9GR1SpPfaomJk6SzgAS-5wKY5G=g@mail.gmail.com>
Hi, David
I have a question, Is the change platform dependent? Looks it is in
shared code.
Thanks
Yumin
On Thu, Jan 5, 2017 at 1:19 PM, David Holmes <david.holmes at oracle.com>
wrote:
> Thanks Karen!
>
> David
>
>
> On 6/01/2017 3:59 AM, Karen Kinnear wrote:
>
>> David,
>>
>> Looks good!
>>
>> thanks,
>> Karen
>>
>> On Jan 4, 2017, at 11:34 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>> Please review this backport of the fix for 8170888, it can't apply
>>> cleanly due to use of unified logging, but that is the only change.
>>>
>>> Original JDK 9 review thread: http://mail.openjdk.java.net/p
>>> ipermail/hotspot-dev/2016-December/025516.html
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
>>>
>>> JDK 9 changeset: http://hg.openjdk.java.net/jdk
>>> 9/jdk9/hotspot/rev/5f1d1df0ea49
>>>
>>> 8u webrev: http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>
>>
From aph at redhat.com Wed Jan 11 15:49:52 2017
From: aph at redhat.com (Andrew Haley)
Date: Wed, 11 Jan 2017 15:49:52 +0000
Subject: JEP 270 concerns
Message-ID: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
I've been porting "JEP 270: Reserved Stack Areas for Critical
Sections" to AArch64. I have no particular concerns about the port,
but I found some serious flaws in testing.
The main problem is that it doesn't work when inlining is enabled. To
demonstrate this fact, remove "-Inline" and add "-Xss512k" to the
runtime arguments in ReservedStackTest. (I tried x86_64 and AArch64.)
The first problem is that the stack walking code in
SharedRuntime::look_for_reserved_stack_annotated_method only looks at
stack frames, not at the methods which have been inlined into compiled
methods. So, if a method marked with a ReservedStackAccess annotation
is inlined, the runtime code will not see the annotation, and the
reserved zone will not be used.
I thought that this was a simple omission, so I changed
look_for_reserved_stack_annotated_method to walk through Scopes
instead of frames, and this indeed detects that a ReservedStackAccess
method has been inlined. However, there is a deeper flaw: once
control is returned to the method which inlines ReservedStackAccess,
the reserved zone remains disabled, so the next time that a method is
called the protection will not be in place.
I think that the only reasonable way to fix this is to force methods
annotated with ReservedStackAccess not to be inlined. It would be
possible to fix this in a better way by changing the logic so that a
runtime call to re-enable reserved zone is inserted at the return of
every ReservedStackAccess-annotated method, but this would be more
complex.
There is another problem: if a callee of a ReservedStackAccess method
makes a runtime call, the yellow zone is disabled; when that runtime
call returns, the yellow zone and the reserved zone are re-eanbled, so
the reserved zone protection is re-enabled while that method is
running. We then return to the ReservedStackAccess method and trigger
an assertion because the reserved zone protection is enabled, which is
unexpected.
Of course I may be very much mistaken about all of this, but I think
not.
Andrew.
From john.r.rose at oracle.com Wed Jan 11 22:16:46 2017
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Jan 2017 14:16:46 -0800
Subject: CFV: New hotspot Group Member: Aleksey Shipilev
In-Reply-To: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
References: <dk68tqo9lxt.fsf@rwestrel.remote.csb>
Message-ID: <8A33C2F7-5486-4732-A849-96A40497A58F@oracle.com>
Vote: yes
From frederic.parain at oracle.com Wed Jan 11 23:47:36 2017
From: frederic.parain at oracle.com (Frederic Parain)
Date: Wed, 11 Jan 2017 18:47:36 -0500
Subject: JEP 270 concerns
In-Reply-To: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
References: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
Message-ID: <3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
Hi Andrew,
Thank you for the deep investigation and the detailed report.
On 01/11/2017 10:49 AM, Andrew Haley wrote:
> I've been porting "JEP 270: Reserved Stack Areas for Critical
> Sections" to AArch64. I have no particular concerns about the port,
> but I found some serious flaws in testing.
>
> The main problem is that it doesn't work when inlining is enabled. To
> demonstrate this fact, remove "-Inline" and add "-Xss512k" to the
> runtime arguments in ReservedStackTest. (I tried x86_64 and AArch64.)
>
> The first problem is that the stack walking code in
> SharedRuntime::look_for_reserved_stack_annotated_method only looks at
> stack frames, not at the methods which have been inlined into compiled
> methods. So, if a method marked with a ReservedStackAccess annotation
> is inlined, the runtime code will not see the annotation, and the
> reserved zone will not be used.
JEP 270 tried to resolve a very specific problem with stack overflows
occurring in critical sections. When an annotated method m1 is inlined,
in a method m2, m2 includes the stack requirements of m1 in the
computation of its stack requirements. So no stack overflow is
possible when m1 is "called (not really a call because of inlining).
However, it only works if m1 is a leaf. If m1 calls another method
and this method is not inlined, then I agree there is a case that
has been missed here.
> I thought that this was a simple omission, so I changed
> look_for_reserved_stack_annotated_method to walk through Scopes
> instead of frames, and this indeed detects that a ReservedStackAccess
> method has been inlined. However, there is a deeper flaw: once
> control is returned to the method which inlines ReservedStackAccess,
> the reserved zone remains disabled, so the next time that a method is
> called the protection will not be in place.
Regarding the very particular usage of the annotation, it could be
acceptable that a method which inlines an annotated method keeps
access to the ReservedStackArea. This is not ideal, but it won't
be worse than the situation before, and it would help anyway in
some cases.
Please, could you sent me your code using Scopes? I'd like to
experiment with it.
> I think that the only reasonable way to fix this is to force methods
> annotated with ReservedStackAccess not to be inlined.
JEP 270's goal is definitively not to prevent in-lining of the
critical methods using the annotation.
> It would be
> possible to fix this in a better way by changing the logic so that a
> runtime call to re-enable reserved zone is inserted at the return of
> every ReservedStackAccess-annotated method, but this would be more
> complex.
This looks too expensive to me regarding the problem the
ReservedStackArea tries to mitigate. It is possible to test with
assembly code if the reserved area has been disabled or not (with
the JavaThread::_reserved_stack_activation).
It seems that there's a trade-off here between guaranteeing the
exact granularity of the annotation and preserving the performances
of in-lining. I think the later is the more important.
Could widening the scope of the of the annotation in case of in-lining,
to include methods in which annotated methods are in-lined, be an
acceptable solution?
> There is another problem: if a callee of a ReservedStackAccess method
> makes a runtime call, the yellow zone is disabled; when that runtime
> call returns, the yellow zone and the reserved zone are re-eanbled, so
> the reserved zone protection is re-enabled while that method is
> running. We then return to the ReservedStackAccess method and trigger
> an assertion because the reserved zone protection is enabled, which is
> unexpected.
If the yellow zone has been disabled, it means that a StackOverflowError
has been thrown. If it happens, it means that the ReservedStackArea
was sizing too small. But even if a StackOverflowError is thrown in
an annotated section, it should not trigger an assertion failure,
so this is clearly a bug.
> Of course I may be very much mistaken about all of this, but I think
> not.
Your insights were very helpful on the in-lining issue.
Regards,
Fred
From aph at redhat.com Thu Jan 12 12:19:48 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Jan 2017 12:19:48 +0000
Subject: JEP 270 concerns
In-Reply-To: <3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
References: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
<3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
Message-ID: <676313e2-f83f-f06e-0cad-26cdd449c709@redhat.com>
Hi,
On 11/01/17 23:47, Frederic Parain wrote:
>
> JEP 270 tried to resolve a very specific problem with stack overflows
> occurring in critical sections. When an annotated method m1 is inlined,
> in a method m2, m2 includes the stack requirements of m1 in the
> computation of its stack requirements. So no stack overflow is
> possible when m1 is "called (not really a call because of inlining).
> However, it only works if m1 is a leaf. If m1 calls another method
> and this method is not inlined, then I agree there is a case that
> has been missed here.
Right, but even in the jtreg case, m1 is not a leaf: it is
nonfairTryAcquire. This calls getExclusiveOwnerThread, which is the
method that overflows the stack. And
look_for_reserved_stack_annotated_method does not see the method which is
at the top anyway, so I think that a ReservedStackAccess method cannot
itself use the reserved area: it has to be one of its callees.
>> I thought that this was a simple omission, so I changed
>> look_for_reserved_stack_annotated_method to walk through Scopes
>> instead of frames, and this indeed detects that a ReservedStackAccess
>> method has been inlined. However, there is a deeper flaw: once
>> control is returned to the method which inlines ReservedStackAccess,
>> the reserved zone remains disabled, so the next time that a method is
>> called the protection will not be in place.
>
> Regarding the very particular usage of the annotation, it could be
> acceptable that a method which inlines an annotated method keeps
> access to the ReservedStackArea. This is not ideal, but it won't
> be worse than the situation before, and it would help anyway in
> some cases.
I guess so, but IMO the logic which handles a stack overflow when the
reserved area is unprotected would have to be fixed so that it doesn't
blindly re-protect the reserved area when it finishes.
> Please, could you sent me your code using Scopes? I'd like to
> experiment with it.
I will.
>> I think that the only reasonable way to fix this is to force methods
>> annotated with ReservedStackAccess not to be inlined.
>
> JEP 270's goal is definitively not to prevent in-lining of the
> critical methods using the annotation.
OK. It's the easy way to make this stuff all come out correctly,
but I understand why not.
>> It would be possible to fix this in a better way by changing the
>> logic so that a runtime call to re-enable reserved zone is inserted
>> at the return of every ReservedStackAccess-annotated method, but
>> this would be more complex.
>
> This looks too expensive to me regarding the problem the
> ReservedStackArea tries to mitigate. It is possible to test with
> assembly code if the reserved area has been disabled or not (with
> the JavaThread::_reserved_stack_activation).
It wouldn't need to be any more expensive: a JIT is quite capable of
inlining the exact same assembly code. It's just more work.
> It seems that there's a trade-off here between guaranteeing the
> exact granularity of the annotation and preserving the performances
> of in-lining. I think the later is the more important.
>
> Could widening the scope of the of the annotation in case of in-lining,
> to include methods in which annotated methods are in-lined, be an
> acceptable solution?
That has a bad code smell, don't you think? To do that you'll have to
change the test so that it works when inlining is enabled: the test
case works around the bug. That feels wrong. I don't think it's in
any sense impossible to make JEP 270 work as designed, even when stuff
is inlined.
Andrew.
From frederic.parain at oracle.com Thu Jan 12 15:28:56 2017
From: frederic.parain at oracle.com (Frederic Parain)
Date: Thu, 12 Jan 2017 10:28:56 -0500
Subject: JEP 270 concerns
In-Reply-To: <676313e2-f83f-f06e-0cad-26cdd449c709@redhat.com>
References: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
<3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
<676313e2-f83f-f06e-0cad-26cdd449c709@redhat.com>
Message-ID: <33d05803-e972-9059-5acf-1d0fc150c20c@oracle.com>
Hi Andrew,
I've re-read the code and my notes and here's
a more accurate description of the way JEP 270
intends to deal with in-lining:
When a method method m1 with the ReservedStackAccess
annotation is in-lined in a method m2, nothing special
is made in the way the method is in-lined and a check
on the reserved stack area is added to m2's return code.
The fact that m1 is a leaf or not doesn't matter (in
fact JEP 270 is important if m1 is not a leaf).
Does it mean that the reserved stack are is not re-enabled
immediately after the execution of an in-lined m1? Yes.
Does it mean m2's code can use the reserved stack area?
No, the stack banging performed at the beginning of m2
ensure that it has enough stack space available without
touching guard pages.
Does it mean that a method called by m2, after an execution
of m1 that trigger access to the reserved stack area, could
use the reserved stack area? Yes, this is unfortunate but
this is part of a trade-off explained below.
However, as you have spotted it, the method
look_for_reserved_stack_annotated_method() fails to detect
in-lined annotated methods. This is clearly a bug which makes
the annotation ineffective for in-lined methods.
The rational of the implementation.
The problem JEP 270 tries to address cannot be solved reliably
in all cases, simply because in Java when a method is invoked,
there's no way to anticipate what the execution will trigger
(class loading for instance).
The consequences of the original bug were considered serious enough
that we would like to mitigate the bug. But the bug occurrences were
also rare, so we didn't want to dedicate too much resources or to
impact performances for a rare bug.
It would be possible to modify the in-lining code to add checks
around an annotated in-lined method. The checks themselves might not
be that expensive (comparing values of
JavaThread::_reserved_stack_activation
before and after the in-lined section is sufficient to detect that
the reserved stack area has been disabled). However, this would
put more constraints on the way the code is in-lined, requiring
to preserve well identified sequences of in-lined code. It was
considered that these constraints would reduce the number of
optimizations the JIT could performed when in-lining methods.
So, instead of modifying the in-lining code, the decision was
made to silently widen the scope of the annotation in case
of in-lining.
Now, if it appears that these hypothesis were wrong, and it
is possible to add the checks in in-lined code without impacting
performances and with a reasonable complexity in the JIT code,
we could revisit these choices. Having the semantic of the
annotation enforced strictly at the granularity of the annotated
method would a nice thing, but how much are we ready to pay for
the protection against this rare bug?
I hope it clarifies the implementation choices that have been
made.
Regards,
Fred
On 01/12/2017 07:19 AM, Andrew Haley wrote:
> Hi,
>
> On 11/01/17 23:47, Frederic Parain wrote:
>>
>> JEP 270 tried to resolve a very specific problem with stack overflows
>> occurring in critical sections. When an annotated method m1 is inlined,
>> in a method m2, m2 includes the stack requirements of m1 in the
>> computation of its stack requirements. So no stack overflow is
>> possible when m1 is "called (not really a call because of inlining).
>> However, it only works if m1 is a leaf. If m1 calls another method
>> and this method is not inlined, then I agree there is a case that
>> has been missed here.
>
> Right, but even in the jtreg case, m1 is not a leaf: it is
> nonfairTryAcquire. This calls getExclusiveOwnerThread, which is the
> method that overflows the stack. And
> look_for_reserved_stack_annotated_method does not see the method which is
> at the top anyway, so I think that a ReservedStackAccess method cannot
> itself use the reserved area: it has to be one of its callees.
>
>>> I thought that this was a simple omission, so I changed
>>> look_for_reserved_stack_annotated_method to walk through Scopes
>>> instead of frames, and this indeed detects that a ReservedStackAccess
>>> method has been inlined. However, there is a deeper flaw: once
>>> control is returned to the method which inlines ReservedStackAccess,
>>> the reserved zone remains disabled, so the next time that a method is
>>> called the protection will not be in place.
>>
>> Regarding the very particular usage of the annotation, it could be
>> acceptable that a method which inlines an annotated method keeps
>> access to the ReservedStackArea. This is not ideal, but it won't
>> be worse than the situation before, and it would help anyway in
>> some cases.
>
> I guess so, but IMO the logic which handles a stack overflow when the
> reserved area is unprotected would have to be fixed so that it doesn't
> blindly re-protect the reserved area when it finishes.
>
>> Please, could you sent me your code using Scopes? I'd like to
>> experiment with it.
>
> I will.
>
>>> I think that the only reasonable way to fix this is to force methods
>>> annotated with ReservedStackAccess not to be inlined.
>>
>> JEP 270's goal is definitively not to prevent in-lining of the
>> critical methods using the annotation.
>
> OK. It's the easy way to make this stuff all come out correctly,
> but I understand why not.
>
>>> It would be possible to fix this in a better way by changing the
>>> logic so that a runtime call to re-enable reserved zone is inserted
>>> at the return of every ReservedStackAccess-annotated method, but
>>> this would be more complex.
>>
>> This looks too expensive to me regarding the problem the
>> ReservedStackArea tries to mitigate. It is possible to test with
>> assembly code if the reserved area has been disabled or not (with
>> the JavaThread::_reserved_stack_activation).
>
> It wouldn't need to be any more expensive: a JIT is quite capable of
> inlining the exact same assembly code. It's just more work.
>
>> It seems that there's a trade-off here between guaranteeing the
>> exact granularity of the annotation and preserving the performances
>> of in-lining. I think the later is the more important.
>>
>> Could widening the scope of the of the annotation in case of in-lining,
>> to include methods in which annotated methods are in-lined, be an
>> acceptable solution?
>
> That has a bad code smell, don't you think? To do that you'll have to
> change the test so that it works when inlining is enabled: the test
> case works around the bug. That feels wrong. I don't think it's in
> any sense impossible to make JEP 270 work as designed, even when stuff
> is inlined.
>
> Andrew.
>
From aph at redhat.com Thu Jan 12 16:03:09 2017
From: aph at redhat.com (Andrew Haley)
Date: Thu, 12 Jan 2017 16:03:09 +0000
Subject: 8172721: Fix for 8172144 breaks AArch64 build
Message-ID: <fa1270b5-1ccd-f47f-73e4-721600ba1322@redhat.com>
My fault: I messed up patch preparation.
http://cr.openjdk.java.net/~aph/8172721/
Thanks,
Andrew.
From dmitry.samersoff at oracle.com Thu Jan 12 16:18:16 2017
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 12 Jan 2017 19:18:16 +0300
Subject: 8172721: Fix for 8172144 breaks AArch64 build
In-Reply-To: <fa1270b5-1ccd-f47f-73e4-721600ba1322@redhat.com>
References: <fa1270b5-1ccd-f47f-73e4-721600ba1322@redhat.com>
Message-ID: <e0cd098d-1f08-fc13-4093-3ed7df75e4bc@oracle.com>
Andrew,
Looks good to me!
-Dmitry
On 2017-01-12 19:03, Andrew Haley wrote:
> My fault: I messed up patch preparation.
>
> http://cr.openjdk.java.net/~aph/8172721/
>
> Thanks,
>
> Andrew.
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
From me at gvsmirnov.ru Thu Jan 12 18:40:03 2017
From: me at gvsmirnov.ru (Gleb Smirnov)
Date: Thu, 12 Jan 2017 21:40:03 +0300
Subject: Backport request for JDK-8034249
Message-ID: <CAE5kBbQfU+AeEuGV=vsrzLt8LSFpDyuyUf_jGAOiGaiCMhSc9g@mail.gmail.com>
Hi all,
We have a java agent that uses JVMTI's GetStackTrace.
As can be seen in [1], there is an issue that may cause
the JVM to crash when it is invoked. The issue was fixed
for jdk9 in 2014, but as far as I can tell, it was not
backported to jdk8. We have quite a few customer JVMs
crashing because of this.
Is there any particular reason for not backporting?
If not, would anyone be so kind as to do it? Can I
help the effort in any way?
Thank you.
Kind Regards,
Gleb Smirnov
[1] https://bugs.openjdk.java.net/browse/JDK-8034249
From vladimir.kozlov at oracle.com Thu Jan 12 19:54:21 2017
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 12 Jan 2017 11:54:21 -0800
Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now
In-Reply-To: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com>
References: <586BF343.7040608@oracle.com>
<CA+3eh10QhjK5KQ8Fsx3XZYdc6Lor7ShdUp5ZujTkYZ4hACPYsA@mail.gmail.com>
<3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com>
Message-ID: <e9d82a38-f55a-7a2f-6995-52e12b9c9206@oracle.com>
Hi Volker,
The general internal Oracle consensus after discussions was that we may
allow only very small high priority RFEs for external ports code. It
should use FC extension process we used before (labels and request
comments) and approved case by case. And this is for limited time only -
we all want to have jdk 9 stable on all platforms when it is released as
Andrew said.
And definitely not if changes touch a common code. If you need then
split it into separate changes as bug if possible - I assume you can
have cases when you need to add #ifdef into existing tests, for example.
Also I would like again to enforce priority limit to P1-P3. If you think
a fix should go into jdk 9 it should have high priority. Otherwise it
can wait jdk 10.
Regards,
Vladimir
On 1/4/17 11:30 AM, Vladimir Kozlov wrote:
> On 1/4/17 2:23 AM, Volker Simonis wrote:
>> On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov
>> <vladimir.kozlov at oracle.com> wrote:
>>> We are currently in "Rampdown" phase for jdk 9 which allows only
>>> P1-P3 bugs
>>> fixes. Note for Hotspot it started week ago.
>>>
>>> http://openjdk.java.net/projects/jdk9/
>>>
>>> Please, make sure bugs you are planning to fix have P1-P3 priority
>>> and "fix
>>> version" is jdk 9. I just updated JDK-8171266 [1] for that.
>>>
>>
>> Thanks a lot Vladimir. I'll push it today.
>>
>> Just for clarification: do the "Rampdown phase rules" also apply to
>> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed
>> to push non P1-P3 bugs or enhancements even in later phases as long as
>> they didn't touch shared code. Is this still allowed or do we now have
>> to strictly conform to the process even for ppc64/s390x-only changes?
>
> JDK 9 schedule was approved by all, including Java Community outside
> Oracle.
>
> I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and
> there were no exceptions listed:
>
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
>
> But I understand that JDK 9 schedule reflects the process inside Oracle
> and may not be applied directly to your process.
> I will try to clarify situation with your ports regarding JDK 9 schedule
> and inform you.
>
> Regards,
> Vladimir
>
>>
>> Thanks a lot and best regards,
>> Volker
>>
>>> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or
>>> defer it to jdk 10 - set "fix version" to 10.
>>>
>>> I see 3 aarch64 P4-P5 bugs which should be updated accordingly:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8170101
>>> https://bugs.openjdk.java.net/browse/JDK-8170103
>>> https://bugs.openjdk.java.net/browse/JDK-8165058
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8171266
>>> "PPC64: Add support to -XX:RTMSpinLoopCount=0"
>>>
From serguei.spitsyn at oracle.com Fri Jan 13 03:18:53 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 12 Jan 2017 19:18:53 -0800
Subject: Backport request for JDK-8034249
In-Reply-To: <CAE5kBbQfU+AeEuGV=vsrzLt8LSFpDyuyUf_jGAOiGaiCMhSc9g@mail.gmail.com>
References: <CAE5kBbQfU+AeEuGV=vsrzLt8LSFpDyuyUf_jGAOiGaiCMhSc9g@mail.gmail.com>
Message-ID: <20cb4a6f-dd87-c006-3106-c10155d6ce97@oracle.com>
Hi Gleb,
I do not see big problems to backport it to the jdk8 yet.
But let me check the jdk8 repository first.
What tool is it for?
Just better to have this info for backport justification.
Thanks,
Serguei
On 1/12/17 10:40, Gleb Smirnov wrote:
> Hi all,
>
> We have a java agent that uses JVMTI's GetStackTrace.
> As can be seen in [1], there is an issue that may cause
> the JVM to crash when it is invoked. The issue was fixed
> for jdk9 in 2014, but as far as I can tell, it was not
> backported to jdk8. We have quite a few customer JVMs
> crashing because of this.
>
> Is there any particular reason for not backporting?
> If not, would anyone be so kind as to do it? Can I
> help the effort in any way?
>
> Thank you.
>
> Kind Regards,
> Gleb Smirnov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8034249
From volker.simonis at gmail.com Fri Jan 13 08:18:12 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 13 Jan 2017 09:18:12 +0100
Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now
In-Reply-To: <e9d82a38-f55a-7a2f-6995-52e12b9c9206@oracle.com>
References: <586BF343.7040608@oracle.com>
<CA+3eh10QhjK5KQ8Fsx3XZYdc6Lor7ShdUp5ZujTkYZ4hACPYsA@mail.gmail.com>
<3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com>
<e9d82a38-f55a-7a2f-6995-52e12b9c9206@oracle.com>
Message-ID: <CA+3eh12WmFy1PAbuadJxwA2ODnOJpwu5M7WQA_Sr5jyZgmFCOw@mail.gmail.com>
OK, got it.
Thanks for the clarification,
Volker
On Thu, Jan 12, 2017 at 8:54 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Hi Volker,
>
> The general internal Oracle consensus after discussions was that we may
> allow only very small high priority RFEs for external ports code. It should
> use FC extension process we used before (labels and request comments) and
> approved case by case. And this is for limited time only - we all want to
> have jdk 9 stable on all platforms when it is released as Andrew said.
>
> And definitely not if changes touch a common code. If you need then split it
> into separate changes as bug if possible - I assume you can have cases when
> you need to add #ifdef into existing tests, for example.
>
> Also I would like again to enforce priority limit to P1-P3. If you think a
> fix should go into jdk 9 it should have high priority. Otherwise it can wait
> jdk 10.
>
> Regards,
> Vladimir
>
>
> On 1/4/17 11:30 AM, Vladimir Kozlov wrote:
>>
>> On 1/4/17 2:23 AM, Volker Simonis wrote:
>>>
>>> On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov
>>> <vladimir.kozlov at oracle.com> wrote:
>>>>
>>>> We are currently in "Rampdown" phase for jdk 9 which allows only
>>>> P1-P3 bugs
>>>> fixes. Note for Hotspot it started week ago.
>>>>
>>>> http://openjdk.java.net/projects/jdk9/
>>>>
>>>> Please, make sure bugs you are planning to fix have P1-P3 priority
>>>> and "fix
>>>> version" is jdk 9. I just updated JDK-8171266 [1] for that.
>>>>
>>>
>>> Thanks a lot Vladimir. I'll push it today.
>>>
>>> Just for clarification: do the "Rampdown phase rules" also apply to
>>> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed
>>> to push non P1-P3 bugs or enhancements even in later phases as long as
>>> they didn't touch shared code. Is this still allowed or do we now have
>>> to strictly conform to the process even for ppc64/s390x-only changes?
>>
>>
>> JDK 9 schedule was approved by all, including Java Community outside
>> Oracle.
>>
>> I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and
>> there were no exceptions listed:
>>
>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
>>
>> But I understand that JDK 9 schedule reflects the process inside Oracle
>> and may not be applied directly to your process.
>> I will try to clarify situation with your ports regarding JDK 9 schedule
>> and inform you.
>>
>> Regards,
>> Vladimir
>>
>>>
>>> Thanks a lot and best regards,
>>> Volker
>>>
>>>> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or
>>>> defer it to jdk 10 - set "fix version" to 10.
>>>>
>>>> I see 3 aarch64 P4-P5 bugs which should be updated accordingly:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8170101
>>>> https://bugs.openjdk.java.net/browse/JDK-8170103
>>>> https://bugs.openjdk.java.net/browse/JDK-8165058
>>>>
>>>> Thanks,
>>>> Vladimir
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8171266
>>>> "PPC64: Add support to -XX:RTMSpinLoopCount=0"
>>>>
>
From aph at redhat.com Fri Jan 13 08:50:50 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Jan 2017 08:50:50 +0000
Subject: JEP 270 concerns
In-Reply-To: <33d05803-e972-9059-5acf-1d0fc150c20c@oracle.com>
References: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
<3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
<676313e2-f83f-f06e-0cad-26cdd449c709@redhat.com>
<33d05803-e972-9059-5acf-1d0fc150c20c@oracle.com>
Message-ID: <6a0a9f3e-8c9f-0c95-b920-9bf09934768d@redhat.com>
On 12/01/17 15:28, Frederic Parain wrote:
> Now, if it appears that these hypothesis were wrong, and it
> is possible to add the checks in in-lined code without impacting
> performances and with a reasonable complexity in the JIT code,
> we could revisit these choices. Having the semantic of the
> annotation enforced strictly at the granularity of the annotated
> method would a nice thing, but how much are we ready to pay for
> the protection against this rare bug?
>
> I hope it clarifies the implementation choices that have been
> made.
I take your point. I think two things must be done:
1. Correct the detection of inlined methods. Not difficult, as we
discussed offthread.
2. Fix assertion failures when we get a stack overflow in another
method with protection disabled.
Does that make sense?
Andrew.
From serguei.spitsyn at oracle.com Fri Jan 13 09:56:28 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 13 Jan 2017 01:56:28 -0800
Subject: Backport request for JDK-8034249
In-Reply-To: <CAE5kBbT0-Zzc18ic6hDkZsF9U26akhDYWcvyz=DzeYSfui1k1g@mail.gmail.com>
References: <CAE5kBbQfU+AeEuGV=vsrzLt8LSFpDyuyUf_jGAOiGaiCMhSc9g@mail.gmail.com>
<20cb4a6f-dd87-c006-3106-c10155d6ce97@oracle.com>
<CAE5kBbT0-Zzc18ic6hDkZsF9U26akhDYWcvyz=DzeYSfui1k1g@mail.gmail.com>
Message-ID: <2c7a06d7-5e6b-e79a-dba7-44122e912298@oracle.com>
Hi Gleb,
Thank you for the reply.
It is good enough.
Thanks,
Serguei
On 1/13/17 01:45, Gleb Smirnov wrote:
> Hi Serguei,
>
> Thanks for getting back to me. If I correctly understand what you mean by "What
> tool is it for?", then the tool is an APM called Plumbr [1]. We use JVMTI to
> capture some evidence required for root cause analysis. It's a shame when this
> leads to JVM crashing.
>
> Please correct me if you asked for something different.
>
> Thank you.
>
> Kind Regards,
> Gleb Smirnov
>
> [1] https://plumbr.eu/how-plumbr-works
>
>
> On Fri, 13 Jan 2017 at 06:18 serguei.spitsyn at oracle.com
> <serguei.spitsyn at oracle.com> wrote:
>> Hi Gleb,
>>
>> I do not see big problems to backport it to the jdk8 yet.
>> But let me check the jdk8 repository first.
>> What tool is it for?
>> Just better to have this info for backport justification.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 1/12/17 10:40, Gleb Smirnov wrote:
>>> Hi all,
>>>
>>> We have a java agent that uses JVMTI's GetStackTrace.
>>> As can be seen in [1], there is an issue that may cause
>>> the JVM to crash when it is invoked. The issue was fixed
>>> for jdk9 in 2014, but as far as I can tell, it was not
>>> backported to jdk8. We have quite a few customer JVMs
>>> crashing because of this.
>>>
>>> Is there any particular reason for not backporting?
>>> If not, would anyone be so kind as to do it? Can I
>>> help the effort in any way?
>>>
>>> Thank you.
>>>
>>> Kind Regards,
>>> Gleb Smirnov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8034249
From frederic.parain at oracle.com Fri Jan 13 14:11:48 2017
From: frederic.parain at oracle.com (Frederic Parain)
Date: Fri, 13 Jan 2017 09:11:48 -0500
Subject: JEP 270 concerns
In-Reply-To: <6a0a9f3e-8c9f-0c95-b920-9bf09934768d@redhat.com>
References: <9a9afaf8-c20e-2853-5d55-c56bf8894836@redhat.com>
<3c814e52-878d-c1af-bf24-ec71348d884d@oracle.com>
<676313e2-f83f-f06e-0cad-26cdd449c709@redhat.com>
<33d05803-e972-9059-5acf-1d0fc150c20c@oracle.com>
<6a0a9f3e-8c9f-0c95-b920-9bf09934768d@redhat.com>
Message-ID: <ae8c318c-0e52-f357-7742-2b88c7638aab@oracle.com>
Hi Andrew,
It makes perfect sense.
I've created bug JDK-8172791 to track these issues.
Thank you for your in-depth analysis of the problems.
Fred
On 01/13/2017 03:50 AM, Andrew Haley wrote:
> On 12/01/17 15:28, Frederic Parain wrote:
>> Now, if it appears that these hypothesis were wrong, and it
>> is possible to add the checks in in-lined code without impacting
>> performances and with a reasonable complexity in the JIT code,
>> we could revisit these choices. Having the semantic of the
>> annotation enforced strictly at the granularity of the annotated
>> method would a nice thing, but how much are we ready to pay for
>> the protection against this rare bug?
>>
>> I hope it clarifies the implementation choices that have been
>> made.
>
> I take your point. I think two things must be done:
>
> 1. Correct the detection of inlined methods. Not difficult, as we
> discussed offthread.
>
> 2. Fix assertion failures when we get a stack overflow in another
> method with protection disabled.
>
> Does that make sense?
>
> Andrew.
>
From tobias.hartmann at oracle.com Fri Jan 13 17:37:15 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Fri, 13 Jan 2017 18:37:15 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails on
solaris-x64 with product build
Message-ID: <5879104B.2010800@oracle.com>
Hi,
please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8172731
http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
The test fails because the VM crashes with a CompilerThreadStackSize of 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not enough to start the VM on Solaris x86. This didn't show up when the fix was integrated because it was only tested with debug builds (with a debug build the number of StackShadowPages is increased by 2 and therefore the minimal CompilerThreadStackSize is larger).
Setting the guard pages to the minimum size via "-XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2" requires a CompilerThreadStackSize of at least 381k to not crash at startup with a product build but the VM only checks for >= 260k. I increased the value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such that the minimum allowed CompilerThreadStackSize is 384k (due to the additional space allocated for guard pages and rounding to the page size).
Tested with failing test, manually and with RBT (running).
Thanks,
Tobias
[1] https://bugs.openjdk.java.net/browse/JDK-8170655
From me at gvsmirnov.ru Fri Jan 13 09:45:41 2017
From: me at gvsmirnov.ru (Gleb Smirnov)
Date: Fri, 13 Jan 2017 12:45:41 +0300
Subject: Backport request for JDK-8034249
In-Reply-To: <20cb4a6f-dd87-c006-3106-c10155d6ce97@oracle.com>
References: <CAE5kBbQfU+AeEuGV=vsrzLt8LSFpDyuyUf_jGAOiGaiCMhSc9g@mail.gmail.com>
<20cb4a6f-dd87-c006-3106-c10155d6ce97@oracle.com>
Message-ID: <CAE5kBbT0-Zzc18ic6hDkZsF9U26akhDYWcvyz=DzeYSfui1k1g@mail.gmail.com>
Hi Serguei,
Thanks for getting back to me. If I correctly understand what you mean by "What
tool is it for?", then the tool is an APM called Plumbr [1]. We use JVMTI to
capture some evidence required for root cause analysis. It's a shame when this
leads to JVM crashing.
Please correct me if you asked for something different.
Thank you.
Kind Regards,
Gleb Smirnov
[1] https://plumbr.eu/how-plumbr-works
On Fri, 13 Jan 2017 at 06:18 serguei.spitsyn at oracle.com
<serguei.spitsyn at oracle.com> wrote:
>
> Hi Gleb,
>
> I do not see big problems to backport it to the jdk8 yet.
> But let me check the jdk8 repository first.
> What tool is it for?
> Just better to have this info for backport justification.
>
> Thanks,
> Serguei
>
>
> On 1/12/17 10:40, Gleb Smirnov wrote:
> > Hi all,
> >
> > We have a java agent that uses JVMTI's GetStackTrace.
> > As can be seen in [1], there is an issue that may cause
> > the JVM to crash when it is invoked. The issue was fixed
> > for jdk9 in 2014, but as far as I can tell, it was not
> > backported to jdk8. We have quite a few customer JVMs
> > crashing because of this.
> >
> > Is there any particular reason for not backporting?
> > If not, would anyone be so kind as to do it? Can I
> > help the effort in any way?
> >
> > Thank you.
> >
> > Kind Regards,
> > Gleb Smirnov
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8034249
>
From serguei.spitsyn at oracle.com Fri Jan 13 18:25:43 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Fri, 13 Jan 2017 10:25:43 -0800
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <5879104B.2010800@oracle.com>
References: <5879104B.2010800@oracle.com>
Message-ID: <b3605cd0-7574-9f99-5996-0e9a20d3c698@oracle.com>
Hi Tobias,
It looks good.
Thanks,
Serguei
On 1/13/17 09:37, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8172731
> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>
> The test fails because the VM crashes with a CompilerThreadStackSize of 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not enough to start the VM on Solaris x86. This didn't show up when the fix was integrated because it was only tested with debug builds (with a debug build the number of StackShadowPages is increased by 2 and therefore the minimal CompilerThreadStackSize is larger).
>
> Setting the guard pages to the minimum size via "-XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2" requires a CompilerThreadStackSize of at least 381k to not crash at startup with a product build but the VM only checks for >= 260k. I increased the value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such that the minimum allowed CompilerThreadStackSize is 384k (due to the additional space allocated for guard pages and rounding to the page size).
>
> Tested with failing test, manually and with RBT (running).
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
From chf at redhat.com Fri Jan 13 19:59:50 2017
From: chf at redhat.com (Christine Flood)
Date: Fri, 13 Jan 2017 14:59:50 -0500 (EST)
Subject: RFR: 8172157: Tighten up contract between concurrent GCs and
runtime regarding object allocation and header initialization
In-Reply-To: <F69D8E71-A7E4-48E5-A035-0D0DBC535DE6@oracle.com>
References: <6EFFB836-BD87-4113-9472-53FE60363511@cavium.com>
<F69D8E71-A7E4-48E5-A035-0D0DBC535DE6@oracle.com>
Message-ID: <2082907836.13548888.1484337590116.JavaMail.zimbra@redhat.com>
Shenandoah is not currently generational, so the comment about tlab allocations being only
in the young generation is not applicable to us.
We scan the object graph concurrently. Assuming that a reference to an object isn't available
until after the object is initialized, and that all objects are correctly formatted at safepoints
we should be fine.
The issue would only come up when walking heap regions. We only do that when we are in an evacuation
phase and the region is in the collection set. We don't allow allocations in regions targeted for
evacuation.
I'm not 100% sure I am grasping all of the subtleties.
Christine
----- Original Message -----
> From: "Kim Barrett" <kim.barrett at oracle.com>
> To: "Derek White" <Derek.White at cavium.com>
> Cc: hotspot-dev at openjdk.java.net, "Christine Flood" <cflood at redhat.com>
> Sent: Wednesday, January 4, 2017 8:22:45 PM
> Subject: Re: RFR: 8172157: Tighten up contract between concurrent GCs and runtime regarding object allocation and
> header initialization
>
> > On Jan 4, 2017, at 6:02 PM, White, Derek <Derek.White at cavium.com> wrote:
> >
> > [resending to hotspot-dev]
> >
> > There are three issues that came up in the review comments for 8171449 that
> > I tried to handle:
> > 1) Inline allocation by jitted code and the interpreter only allocate out
> > of the young gen (either TLABS or eden), and the concurrent GC threads
> > will never scan object in the young gen, so inline-alloctors don't need to
> > ensure memory ordering for the concurrent GC's use. Added comments and
> > assertions.
> >
> > 2) Non-inline allocation in the old gen by a concurrent GC should first set
> > an object?s klass field to NULL before setting it to a correct value.
> > Added comments and assertions.
> > 3) There should be no race condition between the steps in 2 that allows a
> > concurrent GC thread to see an incorrect value. This is harder to prove,
> > and is not handled in this fix.
> >
> > I'm trying to pull some of the constraints out from the depths of the
> > collectors to something closer to the GC/runtime interface, so the non-GC
> > code (writers) can reason about it.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8172157 ?Tighten up contract
> > between concurrent GCs and runtime regarding object allocation and header
> > initialization?
> >
> > Webrev: http://cr.openjdk.java.net/~drwhite/8172157/webrev.02/
> >
> > Thanks,
> >
> > ? Derek
>
> Note that I think this sort of thing is an enhancement, rather than a
> bug as the JIRA issue is presently categorized. Nothing is broken;
> it's just harder to understand and modify the code than we might
> prefer. As such, I think work along this line ought to be deferred
> out of JDK 9.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/collectedHeap.hpp
> 132 // Concurrent collectors must never allocate a TLAB from the old
> generation,
> 133 // because inline-allocation in TLABS by jitted code does not enforce
> 134 // memory ordering consistency for store-length/store-klass, so
> concurrent GC
> 135 // could see inconsistent values when scanning the old gen.
>
> This comment is wrong for a single generation concurent collector.
> Such a collector might still support TLAB allocation for performance.
> It would just have arrange to not look in the TLABs when that would be
> a problem. Consider a SATB-based collector, where allocation is
> black; do something like make TLAB portions from before start of mark
> parsable, and don't scan objects in TLAB portions (possibly entire
> TLABs) allocated from after start of marking. I think Shenandoah
> might be an example of this, and similarly for a collector I worked on
> for a former employer.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/genCollectedHeap.cpp
> 1019 assert(is_in_young((oop)result), "TLAB must be allocated in young
> gen");
>
> I think this assertion is wrong, for the same reason I think the
> comment for allocate_new_tlab is wrong.
>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/genCollectedHeap.cpp
> 492 assert(is_in_young((oop)result) ||
> 493 ((oop)result)->klass_or_null() == NULL,
> 494 "mem_allocate must clear (what will be) the klass field for
> non-young allocations");
>
> I think a more accurate assertion regimen would be to verify
> non-humongous allocations were made from the young gen, and humongous
> allocations have the needed null klass location.
>
> ------------------------------------------------------------------------------
>
> I'm generally suspicious of the proposed comments and assertions. I
> think the actual contracts are not as simple :) as suggested by these
> changes.
>
> For example, for G1, some of the relevant requirements around setup
> and ordering on the allocation side appear to be to support concurrent
> refinement. If using the suggested G1 throughput mode (simpler
> post-barrier, no concurrent refinement), some of those requirements
> might be relaxed, though we might not conditionalize the code.
>
> And for G1 generally, some of the ordering being done on the slow path
> (such as ensuring the length of arrays and classes are set before
> setting the klass field) is only needed when the object is humongous,
> but again here the code isn't conditionalized.
>
> So I think these kind of changes are premature. I think what is first
> needed is some discussion of what the contracts really are, e.g. reify
> the design that is presently implicit in the code. Ideally, this
> should identify parts that are specific to certain GCs or GCs having
> certain properties. Once we have that, then we can start talking
> about how to feed that information back into the code, in the form of
> assertions, conditionalizations, &etc.
>
> An additional benefit of this would be discovery of code bits that
> might be conditionalized as part of the GC abstration layer that has
> been discussed recently. It might also help identify "shared" code
> that is really CMS-specific, in support of CMS deprecation.
>
>
From daniel.daugherty at oracle.com Fri Jan 13 23:03:56 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Fri, 13 Jan 2017 16:03:56 -0700
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <5879104B.2010800@oracle.com>
References: <5879104B.2010800@oracle.com>
Message-ID: <ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
Adding Goetz to this email thread directly.
On 1/13/17 10:37 AM, Tobias Hartmann wrote:
> Hi,
>
> please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8172731
> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
No comments.
Thumbs up! Thanks for fixing this issue.
Goetz, can you please chime in on this thread since you were the
author for:
JDK-8170655: [posix] Fix minimum stack size computations
https://bugs.openjdk.java.net/browse/JDK-8170655
My in-house testing as sponsor didn't catch this issue and now
I look more closely at your testing comment in the bug report,
I don't see Solaris X64 listed.
Dan
>
> The test fails because the VM crashes with a CompilerThreadStackSize of 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not enough to start the VM on Solaris x86. This didn't show up when the fix was integrated because it was only tested with debug builds (with a debug build the number of StackShadowPages is increased by 2 and therefore the minimal CompilerThreadStackSize is larger).
>
> Setting the guard pages to the minimum size via "-XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2" requires a CompilerThreadStackSize of at least 381k to not crash at startup with a product build but the VM only checks for >= 260k. I increased the value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such that the minimum allowed CompilerThreadStackSize is 384k (due to the additional space allocated for guard pages and rounding to the page size).
>
> Tested with failing test, manually and with RBT (running).
>
> Thanks,
> Tobias
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
From goetz.lindenmaier at sap.com Sun Jan 15 10:13:27 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 15 Jan 2017 10:13:27 +0000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
Message-ID: <29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
Hi,
sorry for not testing this platform on my side, but I don't have
a machine to build solaris x86_64 on.
Anyways, this size looks strange. Other platforms get along with 32K and 48K
compiler thread size! Why does this platform need ten times more than others?
Is it because C2 optimizations are configured more aggressive, leading to bigger
compile tasks during startup?
But solaris_sparc also needs a lot (102K) as well as aix (192K). At some point
I'll have a look at why aix needs that much.
Basically this is the right fix for the immediate problem, though. Looks good.
Best regards,
Goetz
> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Samstag, 14. Januar 2017 01:04
> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
> on solaris-x64 with product build
>
> Adding Goetz to this email thread directly.
>
>
> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
> > Hi,
> >
> > please review the following patch:
> > https://bugs.openjdk.java.net/browse/JDK-8172731
> > http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>
> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
> No comments.
>
> Thumbs up! Thanks for fixing this issue.
>
> Goetz, can you please chime in on this thread since you were the
> author for:
>
> JDK-8170655: [posix] Fix minimum stack size computations
> https://bugs.openjdk.java.net/browse/JDK-8170655
>
> My in-house testing as sponsor didn't catch this issue and now
> I look more closely at your testing comment in the bug report,
> I don't see Solaris X64 listed.
>
> Dan
>
>
> >
> > The test fails because the VM crashes with a CompilerThreadStackSize of
> 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows
> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not
> enough to start the VM on Solaris x86. This didn't show up when the fix was
> integrated because it was only tested with debug builds (with a debug build
> the number of StackShadowPages is increased by 2 and therefore the
> minimal CompilerThreadStackSize is larger).
> >
> > Setting the guard pages to the minimum size via "-
> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
> requires a CompilerThreadStackSize of at least 381k to not crash at startup
> with a product build but the VM only checks for >= 260k. I increased the
> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such
> that the minimum allowed CompilerThreadStackSize is 384k (due to the
> additional space allocated for guard pages and rounding to the page size).
> >
> > Tested with failing test, manually and with RBT (running).
> >
> > Thanks,
> > Tobias
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8170655
From david.holmes at oracle.com Sun Jan 15 22:44:50 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2017 08:44:50 +1000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
Message-ID: <3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
My concern with this series of changes is that we're claiming to be
setting shared posix values when it seems in fact the requirements are
different across "posix" platforms. We now penalize all posix platforms
with a larger minimum stack due to this Solaris x64 issue.
I'm also very curious as to why Solaris x64 needs to be different?
David
On 15/01/2017 8:13 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> sorry for not testing this platform on my side, but I don't have
> a machine to build solaris x86_64 on.
> Anyways, this size looks strange. Other platforms get along with 32K and 48K
> compiler thread size! Why does this platform need ten times more than others?
> Is it because C2 optimizations are configured more aggressive, leading to bigger
> compile tasks during startup?
> But solaris_sparc also needs a lot (102K) as well as aix (192K). At some point
> I'll have a look at why aix needs that much.
>
> Basically this is the right fix for the immediate problem, though. Looks good.
>
> Best regards,
> Goetz
>
>
>
>
>
>
>
>
>
>
>
>> -----Original Message-----
>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>> Sent: Samstag, 14. Januar 2017 01:04
>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
>> on solaris-x64 with product build
>>
>> Adding Goetz to this email thread directly.
>>
>>
>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> please review the following patch:
>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>
>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>> No comments.
>>
>> Thumbs up! Thanks for fixing this issue.
>>
>> Goetz, can you please chime in on this thread since you were the
>> author for:
>>
>> JDK-8170655: [posix] Fix minimum stack size computations
>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>
>> My in-house testing as sponsor didn't catch this issue and now
>> I look more closely at your testing comment in the bug report,
>> I don't see Solaris X64 listed.
>>
>> Dan
>>
>>
>>>
>>> The test fails because the VM crashes with a CompilerThreadStackSize of
>> 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows
>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not
>> enough to start the VM on Solaris x86. This didn't show up when the fix was
>> integrated because it was only tested with debug builds (with a debug build
>> the number of StackShadowPages is increased by 2 and therefore the
>> minimal CompilerThreadStackSize is larger).
>>>
>>> Setting the guard pages to the minimum size via "-
>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>> requires a CompilerThreadStackSize of at least 381k to not crash at startup
>> with a product build but the VM only checks for >= 260k. I increased the
>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such
>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>> additional space allocated for guard pages and rounding to the page size).
>>>
>>> Tested with failing test, manually and with RBT (running).
>>>
>>> Thanks,
>>> Tobias
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>
From david.holmes at oracle.com Mon Jan 16 01:35:56 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2017 11:35:56 +1000
Subject: [8u] RFR: 8170888: [linux] Experimental support for cgroup memory
limits in container (ie Docker) environments
In-Reply-To: <CAOEheN5s2L6gqFvHGXfPi=9GR1SpPfaomJk6SzgAS-5wKY5G=g@mail.gmail.com>
References: <c50118e5-5f38-bbdc-81db-4a9d19f97490@oracle.com>
<E3A1A446-E7CB-432F-B0B1-A5CAFEA64A03@oracle.com>
<e814aff6-3465-6aa0-ffcf-0fe193edaeaa@oracle.com>
<CAOEheN5s2L6gqFvHGXfPi=9GR1SpPfaomJk6SzgAS-5wKY5G=g@mail.gmail.com>
Message-ID: <7daf500d-5cd9-4035-d258-8b50f9a9aaf9@oracle.com>
Hi Yumin,
Sorry for the delay, was away last week.
On 11/01/2017 5:45 AM, yumin qi wrote:
> Hi, David
>
> I have a question, Is the change platform dependent? Looks it is in
> shared code.
It is primarily linux-specific, but yes in shared code. However if the
file exists on another platform then you could experiment on that
platform too.
David
> Thanks
> Yumin
>
> On Thu, Jan 5, 2017 at 1:19 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> Thanks Karen!
>
> David
>
>
> On 6/01/2017 3:59 AM, Karen Kinnear wrote:
>
> David,
>
> Looks good!
>
> thanks,
> Karen
>
> On Jan 4, 2017, at 11:34 PM, David Holmes
> <david.holmes at oracle.com <mailto:david.holmes at oracle.com>>
> wrote:
>
> Please review this backport of the fix for 8170888, it can't
> apply cleanly due to use of unified logging, but that is the
> only change.
>
> Original JDK 9 review thread:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html
> <http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025516.html>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8170888
> <https://bugs.openjdk.java.net/browse/JDK-8170888>
>
> JDK 9 changeset:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49 <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5f1d1df0ea49>
>
> 8u webrev:
> http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/
> <http://cr.openjdk.java.net/~dholmes/8170888/webrev.8u/>
>
> Thanks,
> David
> -----
>
>
>
From tobias.hartmann at oracle.com Mon Jan 16 12:15:31 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 16 Jan 2017 13:15:31 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
Message-ID: <587CB963.8070300@oracle.com>
Hi,
thanks to everyone for looking at this.
> My concern with this series of changes is that we're claiming to be setting shared posix values when it seems in fact the requirements are different across "posix" platforms. We now penalize all posix platforms with a larger minimum stack due to this Solaris x64 issue.
Why do we penalize all platforms with this fix? The changes are to 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
> I'm also very curious as to why Solaris x64 needs to be different?
[see below]
>> Anyways, this size looks strange. Other platforms get along with 32K and 48K
>> compiler thread size! Why does this platform need ten times more than others?
>> Is it because C2 optimizations are configured more aggressive, leading to bigger
>> compile tasks during startup?
>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At some point
>> I'll have a look at why aix needs that much.
I don't think it's due to C2 optimizations. They shouldn't differ much on Solaris x86 compared to Linux x86.
I had a closer look at the failures and we always fail in the C2 matcher in the generated method State::MachNodeGenerator(int) which basically consists of a *huge* switch statement matching opcodes. Turns out that with a product build we reserve lots of stack space on method entry:
0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push %rbp
0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp
0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push %r15
0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub $0x53ba8,%rsp
This requires ~335k of stack space whereas a fastdebug build only requires ~15k for the same method:
0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push %rbp
0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp
0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub $0x9430,%rsp
This is consistent with my findings that a fastdebug VM requires a CompilerThreadStackSize of 155k whereas a product build requires 384k.
I guess that this difference is due to more aggressive optimizations done by the Sun Studio Compiler for product builds but from looking at the assembly code, it's not obvious what all that space is actually used for.
Do you think we should file a Sun Studio Compiler bug for this?
>> Basically this is the right fix for the immediate problem, though. Looks good.
Thanks, if there are no objections I would like to push this fix.
Thanks,
Tobias
>>
>> Best regards,
>> Goetz
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>> Sent: Samstag, 14. Januar 2017 01:04
>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
>>> on solaris-x64 with product build
>>>
>>> Adding Goetz to this email thread directly.
>>>
>>>
>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> please review the following patch:
>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>
>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>> No comments.
>>>
>>> Thumbs up! Thanks for fixing this issue.
>>>
>>> Goetz, can you please chime in on this thread since you were the
>>> author for:
>>>
>>> JDK-8170655: [posix] Fix minimum stack size computations
>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>
>>> My in-house testing as sponsor didn't catch this issue and now
>>> I look more closely at your testing comment in the bug report,
>>> I don't see Solaris X64 listed.
>>>
>>> Dan
>>>
>>>
>>>>
>>>> The test fails because the VM crashes with a CompilerThreadStackSize of
>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows
>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not
>>> enough to start the VM on Solaris x86. This didn't show up when the fix was
>>> integrated because it was only tested with debug builds (with a debug build
>>> the number of StackShadowPages is increased by 2 and therefore the
>>> minimal CompilerThreadStackSize is larger).
>>>>
>>>> Setting the guard pages to the minimum size via "-
>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>> requires a CompilerThreadStackSize of at least 381k to not crash at startup
>>> with a product build but the VM only checks for >= 260k. I increased the
>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such
>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>> additional space allocated for guard pages and rounding to the page size).
>>>>
>>>> Tested with failing test, manually and with RBT (running).
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>
From david.holmes at oracle.com Mon Jan 16 12:21:13 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2017 22:21:13 +1000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <587CB963.8070300@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
Message-ID: <66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
> Hi,
>
> thanks to everyone for looking at this.
>
>> My concern with this series of changes is that we're claiming to be setting shared posix values when it seems in fact the requirements are different across "posix" platforms. We now penalize all posix platforms with a larger minimum stack due to this Solaris x64 issue.
>
> Why do we penalize all platforms with this fix? The changes are to 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
Sorry I was mis-remembering that despite being called
os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
specific value.
David
>> I'm also very curious as to why Solaris x64 needs to be different?
>
> [see below]
>
>>> Anyways, this size looks strange. Other platforms get along with 32K and 48K
>>> compiler thread size! Why does this platform need ten times more than others?
>>> Is it because C2 optimizations are configured more aggressive, leading to bigger
>>> compile tasks during startup?
>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At some point
>>> I'll have a look at why aix needs that much.
>
> I don't think it's due to C2 optimizations. They shouldn't differ much on Solaris x86 compared to Linux x86.
>
> I had a closer look at the failures and we always fail in the C2 matcher in the generated method State::MachNodeGenerator(int) which basically consists of a *huge* switch statement matching opcodes. Turns out that with a product build we reserve lots of stack space on method entry:
>
> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push %rbp
> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp
> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push %r15
> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub $0x53ba8,%rsp
>
> This requires ~335k of stack space whereas a fastdebug build only requires ~15k for the same method:
>
> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push %rbp
> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov %rsp,%rbp
> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub $0x9430,%rsp
>
> This is consistent with my findings that a fastdebug VM requires a CompilerThreadStackSize of 155k whereas a product build requires 384k.
>
> I guess that this difference is due to more aggressive optimizations done by the Sun Studio Compiler for product builds but from looking at the assembly code, it's not obvious what all that space is actually used for.
>
> Do you think we should file a Sun Studio Compiler bug for this?
>
>>> Basically this is the right fix for the immediate problem, though. Looks good.
>
> Thanks, if there are no objections I would like to push this fix.
>
> Thanks,
> Tobias
>
>>>
>>> Best regards,
>>> Goetz
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
>>>> on solaris-x64 with product build
>>>>
>>>> Adding Goetz to this email thread directly.
>>>>
>>>>
>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> please review the following patch:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>
>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>> No comments.
>>>>
>>>> Thumbs up! Thanks for fixing this issue.
>>>>
>>>> Goetz, can you please chime in on this thread since you were the
>>>> author for:
>>>>
>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>
>>>> My in-house testing as sponsor didn't catch this issue and now
>>>> I look more closely at your testing comment in the bug report,
>>>> I don't see Solaris X64 listed.
>>>>
>>>> Dan
>>>>
>>>>
>>>>>
>>>>> The test fails because the VM crashes with a CompilerThreadStackSize of
>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which now allows
>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k is not
>>>> enough to start the VM on Solaris x86. This didn't show up when the fix was
>>>> integrated because it was only tested with debug builds (with a debug build
>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>> minimal CompilerThreadStackSize is larger).
>>>>>
>>>>> Setting the guard pages to the minimum size via "-
>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>> requires a CompilerThreadStackSize of at least 381k to not crash at startup
>>>> with a product build but the VM only checks for >= 260k. I increased the
>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to 325 such
>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>> additional space allocated for guard pages and rounding to the page size).
>>>>>
>>>>> Tested with failing test, manually and with RBT (running).
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>
From david.holmes at oracle.com Mon Jan 16 12:33:21 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Jan 2017 22:33:21 +1000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
Message-ID: <6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
Sorry I missed answering the "should we file a studio compiler bug"
question. Don't we generate the MachNodeGenerator code using adlc? What
does the thing we generate actually look like?
David
On 16/01/2017 10:21 PM, David Holmes wrote:
> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> thanks to everyone for looking at this.
>>
>>> My concern with this series of changes is that we're claiming to be
>>> setting shared posix values when it seems in fact the requirements
>>> are different across "posix" platforms. We now penalize all posix
>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>
>> Why do we penalize all platforms with this fix? The changes are to
>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>
> Sorry I was mis-remembering that despite being called
> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
> specific value.
>
> David
>
>>> I'm also very curious as to why Solaris x64 needs to be different?
>>
>> [see below]
>>
>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>> and 48K
>>>> compiler thread size! Why does this platform need ten times more
>>>> than others?
>>>> Is it because C2 optimizations are configured more aggressive,
>>>> leading to bigger
>>>> compile tasks during startup?
>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>> some point
>>>> I'll have a look at why aix needs that much.
>>
>> I don't think it's due to C2 optimizations. They shouldn't differ much
>> on Solaris x86 compared to Linux x86.
>>
>> I had a closer look at the failures and we always fail in the C2
>> matcher in the generated method State::MachNodeGenerator(int) which
>> basically consists of a *huge* switch statement matching opcodes.
>> Turns out that with a product build we reserve lots of stack space on
>> method entry:
>>
>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>> %rbp
>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>> %rsp,%rbp
>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>> %r15
>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>> $0x53ba8,%rsp
>>
>> This requires ~335k of stack space whereas a fastdebug build only
>> requires ~15k for the same method:
>>
>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>> %rbp
>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>> %rsp,%rbp
>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>> $0x9430,%rsp
>>
>> This is consistent with my findings that a fastdebug VM requires a
>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>
>> I guess that this difference is due to more aggressive optimizations
>> done by the Sun Studio Compiler for product builds but from looking at
>> the assembly code, it's not obvious what all that space is actually
>> used for.
>>
>> Do you think we should file a Sun Studio Compiler bug for this?
>>
>>>> Basically this is the right fix for the immediate problem, though.
>>>> Looks good.
>>
>> Thanks, if there are no objections I would like to push this fix.
>>
>> Thanks,
>> Tobias
>>
>>>>
>>>> Best regards,
>>>> Goetz
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>> on solaris-x64 with product build
>>>>>
>>>>> Adding Goetz to this email thread directly.
>>>>>
>>>>>
>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> please review the following patch:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>
>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>> No comments.
>>>>>
>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>
>>>>> Goetz, can you please chime in on this thread since you were the
>>>>> author for:
>>>>>
>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>
>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>> I look more closely at your testing comment in the bug report,
>>>>> I don't see Solaris X64 listed.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>>
>>>>>> The test fails because the VM crashes with a
>>>>>> CompilerThreadStackSize of
>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>> now allows
>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>> is not
>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>> fix was
>>>>> integrated because it was only tested with debug builds (with a
>>>>> debug build
>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>
>>>>>> Setting the guard pages to the minimum size via "-
>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>> startup
>>>>> with a product build but the VM only checks for >= 260k. I
>>>>> increased the
>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>> 325 such
>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>> additional space allocated for guard pages and rounding to the page
>>>>> size).
>>>>>>
>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>
From tobias.hartmann at oracle.com Mon Jan 16 12:38:28 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 16 Jan 2017 13:38:28 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
Message-ID: <587CBEC4.4020304@oracle.com>
Hi David,
On 16.01.2017 13:33, David Holmes wrote:
> Sorry I missed answering the "should we file a studio compiler bug" question. Don't we generate the MachNodeGenerator code using adlc? What does the thing we generate actually look like?
Yes, the C(++) code is generated using adlc. It looks like this:
//------------------------- MachNode Generator ---------------
// A switch statement on the dense-packed user-defined type system
// that invokes 'new' on the corresponding class constructor.
MachNode *State::MachNodeGenerator(int opcode){
switch(opcode) {
case loadB_rule: {
loadBNode *node = new loadBNode();
return node;
}
case loadB2L_rule: {
loadB2LNode *node = new loadB2LNode();
return node;
}
case loadUB_rule: {
loadUBNode *node = new loadUBNode();
return node;
}
case loadUB2L_rule: {
[...]
>
> David
>
> On 16/01/2017 10:21 PM, David Holmes wrote:
>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> thanks to everyone for looking at this.
>>>
>>>> My concern with this series of changes is that we're claiming to be
>>>> setting shared posix values when it seems in fact the requirements
>>>> are different across "posix" platforms. We now penalize all posix
>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>
>>> Why do we penalize all platforms with this fix? The changes are to
>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>
>> Sorry I was mis-remembering that despite being called
>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>> specific value.
Okay, no problem.
Thanks,
Tobias
>>
>> David
>>
>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>
>>> [see below]
>>>
>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>> and 48K
>>>>> compiler thread size! Why does this platform need ten times more
>>>>> than others?
>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>> leading to bigger
>>>>> compile tasks during startup?
>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>> some point
>>>>> I'll have a look at why aix needs that much.
>>>
>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>> on Solaris x86 compared to Linux x86.
>>>
>>> I had a closer look at the failures and we always fail in the C2
>>> matcher in the generated method State::MachNodeGenerator(int) which
>>> basically consists of a *huge* switch statement matching opcodes.
>>> Turns out that with a product build we reserve lots of stack space on
>>> method entry:
>>>
>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>> %rbp
>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>> %rsp,%rbp
>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>> %r15
>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>> $0x53ba8,%rsp
>>>
>>> This requires ~335k of stack space whereas a fastdebug build only
>>> requires ~15k for the same method:
>>>
>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>> %rbp
>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>> %rsp,%rbp
>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>> $0x9430,%rsp
>>>
>>> This is consistent with my findings that a fastdebug VM requires a
>>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>>
>>> I guess that this difference is due to more aggressive optimizations
>>> done by the Sun Studio Compiler for product builds but from looking at
>>> the assembly code, it's not obvious what all that space is actually
>>> used for.
>>>
>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>
>>>>> Basically this is the right fix for the immediate problem, though.
>>>>> Looks good.
>>>
>>> Thanks, if there are no objections I would like to push this fix.
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>>
>>>>> Best regards,
>>>>> Goetz
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>> on solaris-x64 with product build
>>>>>>
>>>>>> Adding Goetz to this email thread directly.
>>>>>>
>>>>>>
>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> please review the following patch:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>
>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>> No comments.
>>>>>>
>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>
>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>> author for:
>>>>>>
>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>
>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>> I look more closely at your testing comment in the bug report,
>>>>>> I don't see Solaris X64 listed.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> The test fails because the VM crashes with a
>>>>>>> CompilerThreadStackSize of
>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>> now allows
>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>>> is not
>>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>>> fix was
>>>>>> integrated because it was only tested with debug builds (with a
>>>>>> debug build
>>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>
>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>> startup
>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>> increased the
>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>> 325 such
>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>>> additional space allocated for guard pages and rounding to the page
>>>>>> size).
>>>>>>>
>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>
From tobias.hartmann at oracle.com Mon Jan 16 14:26:23 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Mon, 16 Jan 2017 15:26:23 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <587CBEC4.4020304@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com>
Message-ID: <587CD80F.2020808@oracle.com>
Hi,
Goetz suggested (off-thread) to add a comment to the patch stating the reason for the large stack size:
http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
Are you fine with that?
Thanks,
Tobias
On 16.01.2017 13:38, Tobias Hartmann wrote:
> Hi David,
>
> On 16.01.2017 13:33, David Holmes wrote:
>> Sorry I missed answering the "should we file a studio compiler bug" question. Don't we generate the MachNodeGenerator code using adlc? What does the thing we generate actually look like?
>
> Yes, the C(++) code is generated using adlc. It looks like this:
>
> //------------------------- MachNode Generator ---------------
> // A switch statement on the dense-packed user-defined type system
> // that invokes 'new' on the corresponding class constructor.
>
> MachNode *State::MachNodeGenerator(int opcode){
> switch(opcode) {
> case loadB_rule: {
> loadBNode *node = new loadBNode();
> return node;
> }
> case loadB2L_rule: {
> loadB2LNode *node = new loadB2LNode();
> return node;
> }
> case loadUB_rule: {
> loadUBNode *node = new loadUBNode();
> return node;
> }
> case loadUB2L_rule: {
>
> [...]
>
>>
>> David
>>
>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> thanks to everyone for looking at this.
>>>>
>>>>> My concern with this series of changes is that we're claiming to be
>>>>> setting shared posix values when it seems in fact the requirements
>>>>> are different across "posix" platforms. We now penalize all posix
>>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>>
>>>> Why do we penalize all platforms with this fix? The changes are to
>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>
>>> Sorry I was mis-remembering that despite being called
>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>>> specific value.
>
> Okay, no problem.
>
> Thanks,
> Tobias
>
>>>
>>> David
>>>
>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>
>>>> [see below]
>>>>
>>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>>> and 48K
>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>> than others?
>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>> leading to bigger
>>>>>> compile tasks during startup?
>>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>>> some point
>>>>>> I'll have a look at why aix needs that much.
>>>>
>>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>>> on Solaris x86 compared to Linux x86.
>>>>
>>>> I had a closer look at the failures and we always fail in the C2
>>>> matcher in the generated method State::MachNodeGenerator(int) which
>>>> basically consists of a *huge* switch statement matching opcodes.
>>>> Turns out that with a product build we reserve lots of stack space on
>>>> method entry:
>>>>
>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>>> %rbp
>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>> %rsp,%rbp
>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>>> %r15
>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>>> $0x53ba8,%rsp
>>>>
>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>> requires ~15k for the same method:
>>>>
>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>>> %rbp
>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>> %rsp,%rbp
>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>>> $0x9430,%rsp
>>>>
>>>> This is consistent with my findings that a fastdebug VM requires a
>>>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>>>
>>>> I guess that this difference is due to more aggressive optimizations
>>>> done by the Sun Studio Compiler for product builds but from looking at
>>>> the assembly code, it's not obvious what all that space is actually
>>>> used for.
>>>>
>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>
>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>> Looks good.
>>>>
>>>> Thanks, if there are no objections I would like to push this fix.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Goetz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>> on solaris-x64 with product build
>>>>>>>
>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>
>>>>>>>
>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> please review the following patch:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>
>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>> No comments.
>>>>>>>
>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>
>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>> author for:
>>>>>>>
>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>
>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>> I don't see Solaris X64 listed.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> The test fails because the VM crashes with a
>>>>>>>> CompilerThreadStackSize of
>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>> now allows
>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>>>> is not
>>>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>>>> fix was
>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>> debug build
>>>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>
>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>>> startup
>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>> increased the
>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>> 325 such
>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>>>> additional space allocated for guard pages and rounding to the page
>>>>>>> size).
>>>>>>>>
>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>
From david.holmes at oracle.com Tue Jan 17 00:53:47 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 17 Jan 2017 10:53:47 +1000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <587CD80F.2020808@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
Message-ID: <5ced4cdc-4b12-7b80-1d58-853e699afcfa@oracle.com>
On 17/01/2017 12:26 AM, Tobias Hartmann wrote:
> Hi,
>
> Goetz suggested (off-thread) to add a comment to the patch stating the reason for the large stack size:
> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>
> Are you fine with that?
Probably should say "Solaris Studio" rather than "Sun"
Thanks,
David
> Thanks,
> Tobias
>
> On 16.01.2017 13:38, Tobias Hartmann wrote:
>> Hi David,
>>
>> On 16.01.2017 13:33, David Holmes wrote:
>>> Sorry I missed answering the "should we file a studio compiler bug" question. Don't we generate the MachNodeGenerator code using adlc? What does the thing we generate actually look like?
>>
>> Yes, the C(++) code is generated using adlc. It looks like this:
>>
>> //------------------------- MachNode Generator ---------------
>> // A switch statement on the dense-packed user-defined type system
>> // that invokes 'new' on the corresponding class constructor.
>>
>> MachNode *State::MachNodeGenerator(int opcode){
>> switch(opcode) {
>> case loadB_rule: {
>> loadBNode *node = new loadBNode();
>> return node;
>> }
>> case loadB2L_rule: {
>> loadB2LNode *node = new loadB2LNode();
>> return node;
>> }
>> case loadUB_rule: {
>> loadUBNode *node = new loadUBNode();
>> return node;
>> }
>> case loadUB2L_rule: {
>>
>> [...]
>>
>>>
>>> David
>>>
>>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>>> Hi,
>>>>>
>>>>> thanks to everyone for looking at this.
>>>>>
>>>>>> My concern with this series of changes is that we're claiming to be
>>>>>> setting shared posix values when it seems in fact the requirements
>>>>>> are different across "posix" platforms. We now penalize all posix
>>>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>>>
>>>>> Why do we penalize all platforms with this fix? The changes are to
>>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>>
>>>> Sorry I was mis-remembering that despite being called
>>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>>>> specific value.
>>
>> Okay, no problem.
>>
>> Thanks,
>> Tobias
>>
>>>>
>>>> David
>>>>
>>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>>
>>>>> [see below]
>>>>>
>>>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>>>> and 48K
>>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>>> than others?
>>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>>> leading to bigger
>>>>>>> compile tasks during startup?
>>>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>>>> some point
>>>>>>> I'll have a look at why aix needs that much.
>>>>>
>>>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>>>> on Solaris x86 compared to Linux x86.
>>>>>
>>>>> I had a closer look at the failures and we always fail in the C2
>>>>> matcher in the generated method State::MachNodeGenerator(int) which
>>>>> basically consists of a *huge* switch statement matching opcodes.
>>>>> Turns out that with a product build we reserve lots of stack space on
>>>>> method entry:
>>>>>
>>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>>>> %rbp
>>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>> %rsp,%rbp
>>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>>>> %r15
>>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>>>> $0x53ba8,%rsp
>>>>>
>>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>>> requires ~15k for the same method:
>>>>>
>>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>>>> %rbp
>>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>> %rsp,%rbp
>>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>>>> $0x9430,%rsp
>>>>>
>>>>> This is consistent with my findings that a fastdebug VM requires a
>>>>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>>>>
>>>>> I guess that this difference is due to more aggressive optimizations
>>>>> done by the Sun Studio Compiler for product builds but from looking at
>>>>> the assembly code, it's not obvious what all that space is actually
>>>>> used for.
>>>>>
>>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>>
>>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>>> Looks good.
>>>>>
>>>>> Thanks, if there are no objections I would like to push this fix.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Goetz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>>> on solaris-x64 with product build
>>>>>>>>
>>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> please review the following patch:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>>
>>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>>> No comments.
>>>>>>>>
>>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>>
>>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>>> author for:
>>>>>>>>
>>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>
>>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>>> I don't see Solaris X64 listed.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The test fails because the VM crashes with a
>>>>>>>>> CompilerThreadStackSize of
>>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>>> now allows
>>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>>>>> is not
>>>>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>>>>> fix was
>>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>>> debug build
>>>>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>>
>>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>>>> startup
>>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>>> increased the
>>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>>> 325 such
>>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>>>>> additional space allocated for guard pages and rounding to the page
>>>>>>>> size).
>>>>>>>>>
>>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tobias
>>>>>>>>>
>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>
From daniel.daugherty at oracle.com Tue Jan 17 03:51:46 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 16 Jan 2017 20:51:46 -0700
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <5ced4cdc-4b12-7b80-1d58-853e699afcfa@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
<5ced4cdc-4b12-7b80-1d58-853e699afcfa@oracle.com>
Message-ID: <7f68f95a-32cc-6c56-5112-1e5482e0ba02@oracle.com>
On 1/16/17 5:53 PM, David Holmes wrote:
> On 17/01/2017 12:26 AM, Tobias Hartmann wrote:
>> Hi,
>>
>> Goetz suggested (off-thread) to add a comment to the patch stating
>> the reason for the large stack size:
>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>>
>> Are you fine with that?
>
> Probably should say "Solaris Studio" rather than "Sun"
It would also be good to document that the fastdebug version
requires less stack space than the release version. That bit
of strangeness should be called out clearly...
I'm good with pushing this fix.
Dan
>
> Thanks,
> David
>
>> Thanks,
>> Tobias
>>
>> On 16.01.2017 13:38, Tobias Hartmann wrote:
>>> Hi David,
>>>
>>> On 16.01.2017 13:33, David Holmes wrote:
>>>> Sorry I missed answering the "should we file a studio compiler bug"
>>>> question. Don't we generate the MachNodeGenerator code using adlc?
>>>> What does the thing we generate actually look like?
>>>
>>> Yes, the C(++) code is generated using adlc. It looks like this:
>>>
>>> //------------------------- MachNode Generator ---------------
>>> // A switch statement on the dense-packed user-defined type system
>>> // that invokes 'new' on the corresponding class constructor.
>>>
>>> MachNode *State::MachNodeGenerator(int opcode){
>>> switch(opcode) {
>>> case loadB_rule: {
>>> loadBNode *node = new loadBNode();
>>> return node;
>>> }
>>> case loadB2L_rule: {
>>> loadB2LNode *node = new loadB2LNode();
>>> return node;
>>> }
>>> case loadUB_rule: {
>>> loadUBNode *node = new loadUBNode();
>>> return node;
>>> }
>>> case loadUB2L_rule: {
>>>
>>> [...]
>>>
>>>>
>>>> David
>>>>
>>>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> thanks to everyone for looking at this.
>>>>>>
>>>>>>> My concern with this series of changes is that we're claiming to be
>>>>>>> setting shared posix values when it seems in fact the requirements
>>>>>>> are different across "posix" platforms. We now penalize all posix
>>>>>>> platforms with a larger minimum stack due to this Solaris x64
>>>>>>> issue.
>>>>>>
>>>>>> Why do we penalize all platforms with this fix? The changes are to
>>>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>>>
>>>>> Sorry I was mis-remembering that despite being called
>>>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a
>>>>> platform
>>>>> specific value.
>>>
>>> Okay, no problem.
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>>
>>>>> David
>>>>>
>>>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>>>
>>>>>> [see below]
>>>>>>
>>>>>>>> Anyways, this size looks strange. Other platforms get along
>>>>>>>> with 32K
>>>>>>>> and 48K
>>>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>>>> than others?
>>>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>>>> leading to bigger
>>>>>>>> compile tasks during startup?
>>>>>>>> But solaris_sparc also needs a lot (102K) as well as aix
>>>>>>>> (192K). At
>>>>>>>> some point
>>>>>>>> I'll have a look at why aix needs that much.
>>>>>>
>>>>>> I don't think it's due to C2 optimizations. They shouldn't differ
>>>>>> much
>>>>>> on Solaris x86 compared to Linux x86.
>>>>>>
>>>>>> I had a closer look at the failures and we always fail in the C2
>>>>>> matcher in the generated method State::MachNodeGenerator(int) which
>>>>>> basically consists of a *huge* switch statement matching opcodes.
>>>>>> Turns out that with a product build we reserve lots of stack
>>>>>> space on
>>>>>> method entry:
>>>>>>
>>>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>>>>> %rbp
>>>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>> %rsp,%rbp
>>>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>>>>> %r15
>>>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>>>>> $0x53ba8,%rsp
>>>>>>
>>>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>>>> requires ~15k for the same method:
>>>>>>
>>>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>>>>> %rbp
>>>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>> %rsp,%rbp
>>>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>>>>> $0x9430,%rsp
>>>>>>
>>>>>> This is consistent with my findings that a fastdebug VM requires a
>>>>>> CompilerThreadStackSize of 155k whereas a product build requires
>>>>>> 384k.
>>>>>>
>>>>>> I guess that this difference is due to more aggressive optimizations
>>>>>> done by the Sun Studio Compiler for product builds but from
>>>>>> looking at
>>>>>> the assembly code, it's not obvious what all that space is actually
>>>>>> used for.
>>>>>>
>>>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>>>
>>>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>>>> Looks good.
>>>>>>
>>>>>> Thanks, if there are no objections I would like to push this fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>>>> on solaris-x64 with product build
>>>>>>>>>
>>>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following patch:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>>>
>>>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>>>> No comments.
>>>>>>>>>
>>>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>>>
>>>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>>>> author for:
>>>>>>>>>
>>>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>>
>>>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>>>> I don't see Solaris X64 listed.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The test fails because the VM crashes with a
>>>>>>>>>> CompilerThreadStackSize of
>>>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>>>> now allows
>>>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k.
>>>>>>>>> 300k
>>>>>>>>> is not
>>>>>>>>> enough to start the VM on Solaris x86. This didn't show up
>>>>>>>>> when the
>>>>>>>>> fix was
>>>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>>>> debug build
>>>>>>>>> the number of StackShadowPages is increased by 2 and therefore
>>>>>>>>> the
>>>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>>>
>>>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1
>>>>>>>>> -XX:StackYellowPages=2"
>>>>>>>>> requires a CompilerThreadStackSize of at least 381k to not
>>>>>>>>> crash at
>>>>>>>>> startup
>>>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>>>> increased the
>>>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>>>> 325 such
>>>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due
>>>>>>>>> to the
>>>>>>>>> additional space allocated for guard pages and rounding to the
>>>>>>>>> page
>>>>>>>>> size).
>>>>>>>>>>
>>>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>>
>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>
From goetz.lindenmaier at sap.com Tue Jan 17 06:17:57 2017
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 17 Jan 2017 06:17:57 +0000
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <587CD80F.2020808@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
Message-ID: <444fc7d2a3654358b3b91f92eda00e9c@DEROTE13DE04.global.corp.sap>
That's good, thanks a lot!
Best regards,
Goetz
> -----Original Message-----
> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
> Sent: Montag, 16. Januar 2017 16:26
> To: David Holmes <david.holmes at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; daniel.daugherty at oracle.com; hotspot-
> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>
> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
> on solaris-x64 with product build
>
> Hi,
>
> Goetz suggested (off-thread) to add a comment to the patch stating the
> reason for the large stack size:
> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>
> Are you fine with that?
>
> Thanks,
> Tobias
>
> On 16.01.2017 13:38, Tobias Hartmann wrote:
> > Hi David,
> >
> > On 16.01.2017 13:33, David Holmes wrote:
> >> Sorry I missed answering the "should we file a studio compiler bug"
> question. Don't we generate the MachNodeGenerator code using adlc? What
> does the thing we generate actually look like?
> >
> > Yes, the C(++) code is generated using adlc. It looks like this:
> >
> > //------------------------- MachNode Generator ---------------
> > // A switch statement on the dense-packed user-defined type system
> > // that invokes 'new' on the corresponding class constructor.
> >
> > MachNode *State::MachNodeGenerator(int opcode){
> > switch(opcode) {
> > case loadB_rule: {
> > loadBNode *node = new loadBNode();
> > return node;
> > }
> > case loadB2L_rule: {
> > loadB2LNode *node = new loadB2LNode();
> > return node;
> > }
> > case loadUB_rule: {
> > loadUBNode *node = new loadUBNode();
> > return node;
> > }
> > case loadUB2L_rule: {
> >
> > [...]
> >
> >>
> >> David
> >>
> >> On 16/01/2017 10:21 PM, David Holmes wrote:
> >>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
> >>>> Hi,
> >>>>
> >>>> thanks to everyone for looking at this.
> >>>>
> >>>>> My concern with this series of changes is that we're claiming to be
> >>>>> setting shared posix values when it seems in fact the requirements
> >>>>> are different across "posix" platforms. We now penalize all posix
> >>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
> >>>>
> >>>> Why do we penalize all platforms with this fix? The changes are to
> >>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
> >>>
> >>> Sorry I was mis-remembering that despite being called
> >>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
> >>> specific value.
> >
> > Okay, no problem.
> >
> > Thanks,
> > Tobias
> >
> >>>
> >>> David
> >>>
> >>>>> I'm also very curious as to why Solaris x64 needs to be different?
> >>>>
> >>>> [see below]
> >>>>
> >>>>>> Anyways, this size looks strange. Other platforms get along with 32K
> >>>>>> and 48K
> >>>>>> compiler thread size! Why does this platform need ten times more
> >>>>>> than others?
> >>>>>> Is it because C2 optimizations are configured more aggressive,
> >>>>>> leading to bigger
> >>>>>> compile tasks during startup?
> >>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
> >>>>>> some point
> >>>>>> I'll have a look at why aix needs that much.
> >>>>
> >>>> I don't think it's due to C2 optimizations. They shouldn't differ much
> >>>> on Solaris x86 compared to Linux x86.
> >>>>
> >>>> I had a closer look at the failures and we always fail in the C2
> >>>> matcher in the generated method State::MachNodeGenerator(int)
> which
> >>>> basically consists of a *huge* switch statement matching opcodes.
> >>>> Turns out that with a product build we reserve lots of stack space on
> >>>> method entry:
> >>>>
> >>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>:
> push
> >>>> %rbp
> >>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>:
> mov
> >>>> %rsp,%rbp
> >>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>:
> push
> >>>> %r15
> >>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>:
> sub
> >>>> $0x53ba8,%rsp
> >>>>
> >>>> This requires ~335k of stack space whereas a fastdebug build only
> >>>> requires ~15k for the same method:
> >>>>
> >>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>:
> push
> >>>> %rbp
> >>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>:
> mov
> >>>> %rsp,%rbp
> >>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>:
> sub
> >>>> $0x9430,%rsp
> >>>>
> >>>> This is consistent with my findings that a fastdebug VM requires a
> >>>> CompilerThreadStackSize of 155k whereas a product build requires
> 384k.
> >>>>
> >>>> I guess that this difference is due to more aggressive optimizations
> >>>> done by the Sun Studio Compiler for product builds but from looking at
> >>>> the assembly code, it's not obvious what all that space is actually
> >>>> used for.
> >>>>
> >>>> Do you think we should file a Sun Studio Compiler bug for this?
> >>>>
> >>>>>> Basically this is the right fix for the immediate problem, though.
> >>>>>> Looks good.
> >>>>
> >>>> Thanks, if there are no objections I would like to push this fix.
> >>>>
> >>>> Thanks,
> >>>> Tobias
> >>>>
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Goetz
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> >>>>>>> Sent: Samstag, 14. Januar 2017 01:04
> >>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
> >>>>>>> dev at openjdk.java.net Developers <hotspot-
> dev at openjdk.java.net>;
> >>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> >>>>>>> Subject: Re: [9] RFR(S): 8172731:
> >>>>>>> runtime/Thread/TooSmallStackSize.java fails
> >>>>>>> on solaris-x64 with product build
> >>>>>>>
> >>>>>>> Adding Goetz to this email thread directly.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> please review the following patch:
> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
> >>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
> >>>>>>>
> >>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
> >>>>>>> No comments.
> >>>>>>>
> >>>>>>> Thumbs up! Thanks for fixing this issue.
> >>>>>>>
> >>>>>>> Goetz, can you please chime in on this thread since you were the
> >>>>>>> author for:
> >>>>>>>
> >>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
> >>>>>>>
> >>>>>>> My in-house testing as sponsor didn't catch this issue and now
> >>>>>>> I look more closely at your testing comment in the bug report,
> >>>>>>> I don't see Solaris X64 listed.
> >>>>>>>
> >>>>>>> Dan
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The test fails because the VM crashes with a
> >>>>>>>> CompilerThreadStackSize of
> >>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
> >>>>>>> now allows
> >>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k.
> 300k
> >>>>>>> is not
> >>>>>>> enough to start the VM on Solaris x86. This didn't show up when
> the
> >>>>>>> fix was
> >>>>>>> integrated because it was only tested with debug builds (with a
> >>>>>>> debug build
> >>>>>>> the number of StackShadowPages is increased by 2 and therefore
> the
> >>>>>>> minimal CompilerThreadStackSize is larger).
> >>>>>>>>
> >>>>>>>> Setting the guard pages to the minimum size via "-
> >>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -
> XX:StackYellowPages=2"
> >>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
> >>>>>>> startup
> >>>>>>> with a product build but the VM only checks for >= 260k. I
> >>>>>>> increased the
> >>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
> >>>>>>> 325 such
> >>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to
> the
> >>>>>>> additional space allocated for guard pages and rounding to the
> page
> >>>>>>> size).
> >>>>>>>>
> >>>>>>>> Tested with failing test, manually and with RBT (running).
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Tobias
> >>>>>>>>
> >>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
> >>>>>>
From tobias.hartmann at oracle.com Tue Jan 17 07:49:35 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 17 Jan 2017 08:49:35 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <7f68f95a-32cc-6c56-5112-1e5482e0ba02@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
<5ced4cdc-4b12-7b80-1d58-853e699afcfa@oracle.com>
<7f68f95a-32cc-6c56-5112-1e5482e0ba02@oracle.com>
Message-ID: <587DCC8F.60203@oracle.com>
Hi,
On 17.01.2017 04:51, Daniel D. Daugherty wrote:
> On 1/16/17 5:53 PM, David Holmes wrote:
>> On 17/01/2017 12:26 AM, Tobias Hartmann wrote:
>>> Hi,
>>>
>>> Goetz suggested (off-thread) to add a comment to the patch stating the reason for the large stack size:
>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>>>
>>> Are you fine with that?
>>
>> Probably should say "Solaris Studio" rather than "Sun"
Okay, I just added the output of "cc -V". Change it to "Solaris Studio".
> It would also be good to document that the fastdebug version
> requires less stack space than the release version. That bit
> of strangeness should be called out clearly...
Right, I added this to the comment.
> I'm good with pushing this fix.
For the record, I'm pushing this:
http://cr.openjdk.java.net/~thartmann/8172731/webrev.02/
Thanks,
Tobias
>
> Dan
>
>>
>> Thanks,
>> David
>>
>>> Thanks,
>>> Tobias
>>>
>>> On 16.01.2017 13:38, Tobias Hartmann wrote:
>>>> Hi David,
>>>>
>>>> On 16.01.2017 13:33, David Holmes wrote:
>>>>> Sorry I missed answering the "should we file a studio compiler bug" question. Don't we generate the MachNodeGenerator code using adlc? What does the thing we generate actually look like?
>>>>
>>>> Yes, the C(++) code is generated using adlc. It looks like this:
>>>>
>>>> //------------------------- MachNode Generator ---------------
>>>> // A switch statement on the dense-packed user-defined type system
>>>> // that invokes 'new' on the corresponding class constructor.
>>>>
>>>> MachNode *State::MachNodeGenerator(int opcode){
>>>> switch(opcode) {
>>>> case loadB_rule: {
>>>> loadBNode *node = new loadBNode();
>>>> return node;
>>>> }
>>>> case loadB2L_rule: {
>>>> loadB2LNode *node = new loadB2LNode();
>>>> return node;
>>>> }
>>>> case loadUB_rule: {
>>>> loadUBNode *node = new loadUBNode();
>>>> return node;
>>>> }
>>>> case loadUB2L_rule: {
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> David
>>>>>
>>>>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>>>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> thanks to everyone for looking at this.
>>>>>>>
>>>>>>>> My concern with this series of changes is that we're claiming to be
>>>>>>>> setting shared posix values when it seems in fact the requirements
>>>>>>>> are different across "posix" platforms. We now penalize all posix
>>>>>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>>>>>
>>>>>>> Why do we penalize all platforms with this fix? The changes are to
>>>>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>>>>
>>>>>> Sorry I was mis-remembering that despite being called
>>>>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>>>>>> specific value.
>>>>
>>>> Okay, no problem.
>>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>>>>
>>>>>> David
>>>>>>
>>>>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>>>>
>>>>>>> [see below]
>>>>>>>
>>>>>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>>>>>> and 48K
>>>>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>>>>> than others?
>>>>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>>>>> leading to bigger
>>>>>>>>> compile tasks during startup?
>>>>>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>>>>>> some point
>>>>>>>>> I'll have a look at why aix needs that much.
>>>>>>>
>>>>>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>>>>>> on Solaris x86 compared to Linux x86.
>>>>>>>
>>>>>>> I had a closer look at the failures and we always fail in the C2
>>>>>>> matcher in the generated method State::MachNodeGenerator(int) which
>>>>>>> basically consists of a *huge* switch statement matching opcodes.
>>>>>>> Turns out that with a product build we reserve lots of stack space on
>>>>>>> method entry:
>>>>>>>
>>>>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>>>>>> %rbp
>>>>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>>> %rsp,%rbp
>>>>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>>>>>> %r15
>>>>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>>>>>> $0x53ba8,%rsp
>>>>>>>
>>>>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>>>>> requires ~15k for the same method:
>>>>>>>
>>>>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>>>>>> %rbp
>>>>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>>> %rsp,%rbp
>>>>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>>>>>> $0x9430,%rsp
>>>>>>>
>>>>>>> This is consistent with my findings that a fastdebug VM requires a
>>>>>>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>>>>>>
>>>>>>> I guess that this difference is due to more aggressive optimizations
>>>>>>> done by the Sun Studio Compiler for product builds but from looking at
>>>>>>> the assembly code, it's not obvious what all that space is actually
>>>>>>> used for.
>>>>>>>
>>>>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>>>>
>>>>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>>>>> Looks good.
>>>>>>>
>>>>>>> Thanks, if there are no objections I would like to push this fix.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tobias
>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Goetz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>>>>> on solaris-x64 with product build
>>>>>>>>>>
>>>>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> please review the following patch:
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>>>>
>>>>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>>>>> No comments.
>>>>>>>>>>
>>>>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>>>>
>>>>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>>>>> author for:
>>>>>>>>>>
>>>>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>>>
>>>>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>>>>> I don't see Solaris X64 listed.
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The test fails because the VM crashes with a
>>>>>>>>>>> CompilerThreadStackSize of
>>>>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>>>>> now allows
>>>>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>>>>>>> is not
>>>>>>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>>>>>>> fix was
>>>>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>>>>> debug build
>>>>>>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>>>>
>>>>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>>>>>> startup
>>>>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>>>>> increased the
>>>>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>>>>> 325 such
>>>>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>>>>>>> additional space allocated for guard pages and rounding to the page
>>>>>>>>>> size).
>>>>>>>>>>>
>>>>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Tobias
>>>>>>>>>>>
>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>>
>
From tobias.hartmann at oracle.com Tue Jan 17 07:50:05 2017
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Tue, 17 Jan 2017 08:50:05 +0100
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <444fc7d2a3654358b3b91f92eda00e9c@DEROTE13DE04.global.corp.sap>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
<444fc7d2a3654358b3b91f92eda00e9c@DEROTE13DE04.global.corp.sap>
Message-ID: <587DCCAD.1010305@oracle.com>
Thanks, G?tz!
Best regards,
Tobias
On 17.01.2017 07:17, Lindenmaier, Goetz wrote:
> That's good, thanks a lot!
>
> Best regards,
> Goetz
>
>> -----Original Message-----
>> From: Tobias Hartmann [mailto:tobias.hartmann at oracle.com]
>> Sent: Montag, 16. Januar 2017 16:26
>> To: David Holmes <david.holmes at oracle.com>; Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>; daniel.daugherty at oracle.com; hotspot-
>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>
>> Subject: Re: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
>> on solaris-x64 with product build
>>
>> Hi,
>>
>> Goetz suggested (off-thread) to add a comment to the patch stating the
>> reason for the large stack size:
>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>>
>> Are you fine with that?
>>
>> Thanks,
>> Tobias
>>
>> On 16.01.2017 13:38, Tobias Hartmann wrote:
>>> Hi David,
>>>
>>> On 16.01.2017 13:33, David Holmes wrote:
>>>> Sorry I missed answering the "should we file a studio compiler bug"
>> question. Don't we generate the MachNodeGenerator code using adlc? What
>> does the thing we generate actually look like?
>>>
>>> Yes, the C(++) code is generated using adlc. It looks like this:
>>>
>>> //------------------------- MachNode Generator ---------------
>>> // A switch statement on the dense-packed user-defined type system
>>> // that invokes 'new' on the corresponding class constructor.
>>>
>>> MachNode *State::MachNodeGenerator(int opcode){
>>> switch(opcode) {
>>> case loadB_rule: {
>>> loadBNode *node = new loadBNode();
>>> return node;
>>> }
>>> case loadB2L_rule: {
>>> loadB2LNode *node = new loadB2LNode();
>>> return node;
>>> }
>>> case loadUB_rule: {
>>> loadUBNode *node = new loadUBNode();
>>> return node;
>>> }
>>> case loadUB2L_rule: {
>>>
>>> [...]
>>>
>>>>
>>>> David
>>>>
>>>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>>>> Hi,
>>>>>>
>>>>>> thanks to everyone for looking at this.
>>>>>>
>>>>>>> My concern with this series of changes is that we're claiming to be
>>>>>>> setting shared posix values when it seems in fact the requirements
>>>>>>> are different across "posix" platforms. We now penalize all posix
>>>>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>>>>
>>>>>> Why do we penalize all platforms with this fix? The changes are to
>>>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>>>
>>>>> Sorry I was mis-remembering that despite being called
>>>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>>>>> specific value.
>>>
>>> Okay, no problem.
>>>
>>> Thanks,
>>> Tobias
>>>
>>>>>
>>>>> David
>>>>>
>>>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>>>
>>>>>> [see below]
>>>>>>
>>>>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>>>>> and 48K
>>>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>>>> than others?
>>>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>>>> leading to bigger
>>>>>>>> compile tasks during startup?
>>>>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>>>>> some point
>>>>>>>> I'll have a look at why aix needs that much.
>>>>>>
>>>>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>>>>> on Solaris x86 compared to Linux x86.
>>>>>>
>>>>>> I had a closer look at the failures and we always fail in the C2
>>>>>> matcher in the generated method State::MachNodeGenerator(int)
>> which
>>>>>> basically consists of a *huge* switch statement matching opcodes.
>>>>>> Turns out that with a product build we reserve lots of stack space on
>>>>>> method entry:
>>>>>>
>>>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>:
>> push
>>>>>> %rbp
>>>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>:
>> mov
>>>>>> %rsp,%rbp
>>>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>:
>> push
>>>>>> %r15
>>>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>:
>> sub
>>>>>> $0x53ba8,%rsp
>>>>>>
>>>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>>>> requires ~15k for the same method:
>>>>>>
>>>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>:
>> push
>>>>>> %rbp
>>>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>:
>> mov
>>>>>> %rsp,%rbp
>>>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>:
>> sub
>>>>>> $0x9430,%rsp
>>>>>>
>>>>>> This is consistent with my findings that a fastdebug VM requires a
>>>>>> CompilerThreadStackSize of 155k whereas a product build requires
>> 384k.
>>>>>>
>>>>>> I guess that this difference is due to more aggressive optimizations
>>>>>> done by the Sun Studio Compiler for product builds but from looking at
>>>>>> the assembly code, it's not obvious what all that space is actually
>>>>>> used for.
>>>>>>
>>>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>>>
>>>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>>>> Looks good.
>>>>>>
>>>>>> Thanks, if there are no objections I would like to push this fix.
>>>>>>
>>>>>> Thanks,
>>>>>> Tobias
>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>>>> dev at openjdk.java.net Developers <hotspot-
>> dev at openjdk.java.net>;
>>>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>>>> on solaris-x64 with product build
>>>>>>>>>
>>>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following patch:
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>>>
>>>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>>>> No comments.
>>>>>>>>>
>>>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>>>
>>>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>>>> author for:
>>>>>>>>>
>>>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>>
>>>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>>>> I don't see Solaris X64 listed.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The test fails because the VM crashes with a
>>>>>>>>>> CompilerThreadStackSize of
>>>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>>>> now allows
>>>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k.
>> 300k
>>>>>>>>> is not
>>>>>>>>> enough to start the VM on Solaris x86. This didn't show up when
>> the
>>>>>>>>> fix was
>>>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>>>> debug build
>>>>>>>>> the number of StackShadowPages is increased by 2 and therefore
>> the
>>>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>>>
>>>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -
>> XX:StackYellowPages=2"
>>>>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>>>>> startup
>>>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>>>> increased the
>>>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>>>> 325 such
>>>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to
>> the
>>>>>>>>> additional space allocated for guard pages and rounding to the
>> page
>>>>>>>>> size).
>>>>>>>>>>
>>>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tobias
>>>>>>>>>>
>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>
From daniel.daugherty at oracle.com Tue Jan 17 14:29:51 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 17 Jan 2017 07:29:51 -0700
Subject: [9] RFR(S): 8172731: runtime/Thread/TooSmallStackSize.java fails
on solaris-x64 with product build
In-Reply-To: <587DCC8F.60203@oracle.com>
References: <5879104B.2010800@oracle.com>
<ca9a0e79-b934-59f7-eec2-e1a239b1dbb6@oracle.com>
<29bee38c57ae45d698bab501b4d89146@DEROTE13DE08.global.corp.sap>
<3faed1c1-bc19-9810-15f5-96dfc03558fb@oracle.com>
<587CB963.8070300@oracle.com>
<66435bc1-6f92-278a-2816-58b5cd6e764d@oracle.com>
<6097ccc5-14d1-bb58-5793-20456eb0896a@oracle.com>
<587CBEC4.4020304@oracle.com> <587CD80F.2020808@oracle.com>
<5ced4cdc-4b12-7b80-1d58-853e699afcfa@oracle.com>
<7f68f95a-32cc-6c56-5112-1e5482e0ba02@oracle.com>
<587DCC8F.60203@oracle.com>
Message-ID: <fe669af3-8338-2fef-47a1-c22a06030057@oracle.com>
On 1/17/17 12:49 AM, Tobias Hartmann wrote:
> Hi,
>
> On 17.01.2017 04:51, Daniel D. Daugherty wrote:
>> On 1/16/17 5:53 PM, David Holmes wrote:
>>> On 17/01/2017 12:26 AM, Tobias Hartmann wrote:
>>>> Hi,
>>>>
>>>> Goetz suggested (off-thread) to add a comment to the patch stating the reason for the large stack size:
>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.01/
>>>>
>>>> Are you fine with that?
>>> Probably should say "Solaris Studio" rather than "Sun"
> Okay, I just added the output of "cc -V". Change it to "Solaris Studio".
>
>> It would also be good to document that the fastdebug version
>> requires less stack space than the release version. That bit
>> of strangeness should be called out clearly...
> Right, I added this to the comment.
>
>> I'm good with pushing this fix.
> For the record, I'm pushing this:
> http://cr.openjdk.java.net/~thartmann/8172731/webrev.02/
Looks good to me.
Again, thanks for fixing this bug.
Dan
>
> Thanks,
> Tobias
>
>> Dan
>>
>>> Thanks,
>>> David
>>>
>>>> Thanks,
>>>> Tobias
>>>>
>>>> On 16.01.2017 13:38, Tobias Hartmann wrote:
>>>>> Hi David,
>>>>>
>>>>> On 16.01.2017 13:33, David Holmes wrote:
>>>>>> Sorry I missed answering the "should we file a studio compiler bug" question. Don't we generate the MachNodeGenerator code using adlc? What does the thing we generate actually look like?
>>>>> Yes, the C(++) code is generated using adlc. It looks like this:
>>>>>
>>>>> //------------------------- MachNode Generator ---------------
>>>>> // A switch statement on the dense-packed user-defined type system
>>>>> // that invokes 'new' on the corresponding class constructor.
>>>>>
>>>>> MachNode *State::MachNodeGenerator(int opcode){
>>>>> switch(opcode) {
>>>>> case loadB_rule: {
>>>>> loadBNode *node = new loadBNode();
>>>>> return node;
>>>>> }
>>>>> case loadB2L_rule: {
>>>>> loadB2LNode *node = new loadB2LNode();
>>>>> return node;
>>>>> }
>>>>> case loadUB_rule: {
>>>>> loadUBNode *node = new loadUBNode();
>>>>> return node;
>>>>> }
>>>>> case loadUB2L_rule: {
>>>>>
>>>>> [...]
>>>>>
>>>>>> David
>>>>>>
>>>>>> On 16/01/2017 10:21 PM, David Holmes wrote:
>>>>>>> On 16/01/2017 10:15 PM, Tobias Hartmann wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> thanks to everyone for looking at this.
>>>>>>>>
>>>>>>>>> My concern with this series of changes is that we're claiming to be
>>>>>>>>> setting shared posix values when it seems in fact the requirements
>>>>>>>>> are different across "posix" platforms. We now penalize all posix
>>>>>>>>> platforms with a larger minimum stack due to this Solaris x64 issue.
>>>>>>>> Why do we penalize all platforms with this fix? The changes are to
>>>>>>>> 'os_solaris_x86.cpp' and only affect a Solaris x86 build.
>>>>>>> Sorry I was mis-remembering that despite being called
>>>>>>> os::Posix::_compiler_thread_min_stack_allowed it is actually a platform
>>>>>>> specific value.
>>>>> Okay, no problem.
>>>>>
>>>>> Thanks,
>>>>> Tobias
>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>>> I'm also very curious as to why Solaris x64 needs to be different?
>>>>>>>> [see below]
>>>>>>>>
>>>>>>>>>> Anyways, this size looks strange. Other platforms get along with 32K
>>>>>>>>>> and 48K
>>>>>>>>>> compiler thread size! Why does this platform need ten times more
>>>>>>>>>> than others?
>>>>>>>>>> Is it because C2 optimizations are configured more aggressive,
>>>>>>>>>> leading to bigger
>>>>>>>>>> compile tasks during startup?
>>>>>>>>>> But solaris_sparc also needs a lot (102K) as well as aix (192K). At
>>>>>>>>>> some point
>>>>>>>>>> I'll have a look at why aix needs that much.
>>>>>>>> I don't think it's due to C2 optimizations. They shouldn't differ much
>>>>>>>> on Solaris x86 compared to Linux x86.
>>>>>>>>
>>>>>>>> I had a closer look at the failures and we always fail in the C2
>>>>>>>> matcher in the generated method State::MachNodeGenerator(int) which
>>>>>>>> basically consists of a *huge* switch statement matching opcodes.
>>>>>>>> Turns out that with a product build we reserve lots of stack space on
>>>>>>>> method entry:
>>>>>>>>
>>>>>>>> 0xffff80ff92537cf0<MachNode*State::MachNodeGenerator(int)>: push
>>>>>>>> %rbp
>>>>>>>> 0xffff80ff92537cf1<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>>>> %rsp,%rbp
>>>>>>>> 0xffff80ff92537cf4<MachNode*State::MachNodeGenerator(int)+4>: push
>>>>>>>> %r15
>>>>>>>> 0xffff80ff92537cf6<MachNode*State::MachNodeGenerator(int)+6>: sub
>>>>>>>> $0x53ba8,%rsp
>>>>>>>>
>>>>>>>> This requires ~335k of stack space whereas a fastdebug build only
>>>>>>>> requires ~15k for the same method:
>>>>>>>>
>>>>>>>> 0xffff80ff7c8a0460<MachNode*State::MachNodeGenerator(int)>: push
>>>>>>>> %rbp
>>>>>>>> 0xffff80ff7c8a0461<MachNode*State::MachNodeGenerator(int)+1>: mov
>>>>>>>> %rsp,%rbp
>>>>>>>> 0xffff80ff7c8a0464<MachNode*State::MachNodeGenerator(int)+4>: sub
>>>>>>>> $0x9430,%rsp
>>>>>>>>
>>>>>>>> This is consistent with my findings that a fastdebug VM requires a
>>>>>>>> CompilerThreadStackSize of 155k whereas a product build requires 384k.
>>>>>>>>
>>>>>>>> I guess that this difference is due to more aggressive optimizations
>>>>>>>> done by the Sun Studio Compiler for product builds but from looking at
>>>>>>>> the assembly code, it's not obvious what all that space is actually
>>>>>>>> used for.
>>>>>>>>
>>>>>>>> Do you think we should file a Sun Studio Compiler bug for this?
>>>>>>>>
>>>>>>>>>> Basically this is the right fix for the immediate problem, though.
>>>>>>>>>> Looks good.
>>>>>>>> Thanks, if there are no objections I would like to push this fix.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Goetz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>>>>>>>>>> Sent: Samstag, 14. Januar 2017 01:04
>>>>>>>>>>> To: Tobias Hartmann <tobias.hartmann at oracle.com>; hotspot-
>>>>>>>>>>> dev at openjdk.java.net Developers <hotspot-dev at openjdk.java.net>;
>>>>>>>>>>> Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>>>>>>>>> Subject: Re: [9] RFR(S): 8172731:
>>>>>>>>>>> runtime/Thread/TooSmallStackSize.java fails
>>>>>>>>>>> on solaris-x64 with product build
>>>>>>>>>>>
>>>>>>>>>>> Adding Goetz to this email thread directly.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/13/17 10:37 AM, Tobias Hartmann wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> please review the following patch:
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8172731
>>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8172731/webrev.00/
>>>>>>>>>>> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp
>>>>>>>>>>> No comments.
>>>>>>>>>>>
>>>>>>>>>>> Thumbs up! Thanks for fixing this issue.
>>>>>>>>>>>
>>>>>>>>>>> Goetz, can you please chime in on this thread since you were the
>>>>>>>>>>> author for:
>>>>>>>>>>>
>>>>>>>>>>> JDK-8170655: [posix] Fix minimum stack size computations
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8170655
>>>>>>>>>>>
>>>>>>>>>>> My in-house testing as sponsor didn't catch this issue and now
>>>>>>>>>>> I look more closely at your testing comment in the bug report,
>>>>>>>>>>> I don't see Solaris X64 listed.
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> The test fails because the VM crashes with a
>>>>>>>>>>>> CompilerThreadStackSize of
>>>>>>>>>>> 300k. The problem is caused by the fix for JDK-8170655 [1] which
>>>>>>>>>>> now allows
>>>>>>>>>>> a minimum CompilerThreadStackSize of 300k, before it was 396k. 300k
>>>>>>>>>>> is not
>>>>>>>>>>> enough to start the VM on Solaris x86. This didn't show up when the
>>>>>>>>>>> fix was
>>>>>>>>>>> integrated because it was only tested with debug builds (with a
>>>>>>>>>>> debug build
>>>>>>>>>>> the number of StackShadowPages is increased by 2 and therefore the
>>>>>>>>>>> minimal CompilerThreadStackSize is larger).
>>>>>>>>>>>> Setting the guard pages to the minimum size via "-
>>>>>>>>>>> XX:StackShadowPages=10 -XX:StackRedPages=1 -XX:StackYellowPages=2"
>>>>>>>>>>> requires a CompilerThreadStackSize of at least 381k to not crash at
>>>>>>>>>>> startup
>>>>>>>>>>> with a product build but the VM only checks for >= 260k. I
>>>>>>>>>>> increased the
>>>>>>>>>>> value of os::Posix::_compiler_thread_min_stack_allowed by 123 to
>>>>>>>>>>> 325 such
>>>>>>>>>>> that the minimum allowed CompilerThreadStackSize is 384k (due to the
>>>>>>>>>>> additional space allocated for guard pages and rounding to the page
>>>>>>>>>>> size).
>>>>>>>>>>>> Tested with failing test, manually and with RBT (running).
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Tobias
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8170655
From coleen.phillimore at oracle.com Tue Jan 17 22:49:24 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Jan 2017 17:49:24 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
Message-ID: <f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
I should have also sent this to hotspot-dev, since Bytecode_tableswitch
is used by the compiler ci code.
thanks,
Coleen
On 1/17/17 1:49 PM, Coleen Phillimore wrote:
> Summary: simplify Bytecode_tableswitch code so windows doesn't
> generate bad code for it.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>
> Verified generated code does not have sign extended value that is
> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
> some -Xcomp tests.
>
> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>
> Thanks,
> Coleen
>
>
From david.holmes at oracle.com Wed Jan 18 00:02:45 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jan 2017 10:02:45 +1000
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
Message-ID: <a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
Hi Coleen,
The bug report does not explain the problem so it is unclear whether
this workaround is minimal. Also some commentary somewhere would be
useful else the bug might return inadvertently - more generally I'd like
to understand what other code might be impacted by this.
Thanks,
David
On 18/01/2017 8:49 AM, Coleen Phillimore wrote:
> I should have also sent this to hotspot-dev, since Bytecode_tableswitch
> is used by the compiler ci code.
> thanks,
> Coleen
>
>
> On 1/17/17 1:49 PM, Coleen Phillimore wrote:
>> Summary: simplify Bytecode_tableswitch code so windows doesn't
>> generate bad code for it.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>>
>> Verified generated code does not have sign extended value that is
>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
>> some -Xcomp tests.
>>
>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>>
>> Thanks,
>> Coleen
>>
>>
>
From coleen.phillimore at oracle.com Wed Jan 18 02:13:13 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Jan 2017 21:13:13 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
Message-ID: <d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
On 1/17/17 7:02 PM, David Holmes wrote:
> Hi Coleen,
>
> The bug report does not explain the problem so it is unclear whether
> this workaround is minimal. Also some commentary somewhere would be
> useful else the bug might return inadvertently - more generally I'd
> like to understand what other code might be impacted by this.
Christian and I spent a solid week looking for the windows Visual Studio
bug that caused this but weren't able to find it. He verified that it's
fixed in VS2015. I think that's in the bug report. The code generated
is in the bug report with annotations of what lines the code it was
executing and which instructions caused the truncation and sign
extension leading to a negative offset from the start of _bcp.
There's a small reproducer in the bug report for 8144518.
I did a grep of all the "address.*-" and looked through the lines of
code but I didn't generate windows assembly code to examine for all the
pointer subtractions. I don't plan to do this. From the reproducer,
there needed to be the swap_u4, even though the load that crashed was
before the swap_u4 code. The scenario that caused this bug seems very
specific and if it exists in any other places in the jvm, we can keep an
eye out for it. This crash, while intermittent, was fairly consistent.
We think it's best to get this workaround into jdk 9 before ZBB since
this bug has been seen several times, and we finally narrowed down the
problem and don't have to close it as not reproduceable again.
There is a line above the dest_offset_at code which I was going to
remove, since it's describing code I changed, which doesn't make for a
good comment. Any further commentary or explanation of this bug will be
vague, since we don't have the VS compiler to debug to find the real
problem, and won't make sense in the source code.
Did you look at the code? It's a simplification of the expression that
was in the original, that would have been better from the start.
Thanks,
Coleen
>
> Thanks,
> David
>
> On 18/01/2017 8:49 AM, Coleen Phillimore wrote:
>> I should have also sent this to hotspot-dev, since Bytecode_tableswitch
>> is used by the compiler ci code.
>> thanks,
>> Coleen
>>
>>
>> On 1/17/17 1:49 PM, Coleen Phillimore wrote:
>>> Summary: simplify Bytecode_tableswitch code so windows doesn't
>>> generate bad code for it.
>>>
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>>>
>>> Verified generated code does not have sign extended value that is
>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
>>> some -Xcomp tests.
>>>
>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>>>
>>> Thanks,
>>> Coleen
>>>
>>>
>>
From coleen.phillimore at oracle.com Wed Jan 18 02:24:01 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 17 Jan 2017 21:24:01 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
Message-ID: <8b8c90b7-92d7-8593-a20c-42038d95a982@oracle.com>
Actually, I did look at Bytecodes::_tableswitch handling through the jvm
and both other instances (verifier and relocator) that don't use
Bytecode_tableswitch use different address calculation. They align the
bcp to u4 first and then do get_Java_u4().
The relocator has the disturbing comment
// We cannot use the Bytecode_tableswitch abstraction,
since the padding might not be correct.
This is because the code stream has had code inserted at this point.
Coleen
On 1/17/17 9:13 PM, Coleen Phillimore wrote:
>
>
> On 1/17/17 7:02 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> The bug report does not explain the problem so it is unclear whether
>> this workaround is minimal. Also some commentary somewhere would be
>> useful else the bug might return inadvertently - more generally I'd
>> like to understand what other code might be impacted by this.
>
> Christian and I spent a solid week looking for the windows Visual
> Studio bug that caused this but weren't able to find it. He verified
> that it's fixed in VS2015. I think that's in the bug report. The
> code generated is in the bug report with annotations of what lines the
> code it was executing and which instructions caused the truncation and
> sign extension leading to a negative offset from the start of _bcp.
>
> There's a small reproducer in the bug report for 8144518.
>
> I did a grep of all the "address.*-" and looked through the lines of
> code but I didn't generate windows assembly code to examine for all
> the pointer subtractions. I don't plan to do this. From the
> reproducer, there needed to be the swap_u4, even though the load that
> crashed was before the swap_u4 code. The scenario that caused this
> bug seems very specific and if it exists in any other places in the
> jvm, we can keep an eye out for it. This crash, while intermittent,
> was fairly consistent.
>
> We think it's best to get this workaround into jdk 9 before ZBB since
> this bug has been seen several times, and we finally narrowed down the
> problem and don't have to close it as not reproduceable again.
>
> There is a line above the dest_offset_at code which I was going to
> remove, since it's describing code I changed, which doesn't make for a
> good comment. Any further commentary or explanation of this bug will
> be vague, since we don't have the VS compiler to debug to find the
> real problem, and won't make sense in the source code.
>
> Did you look at the code? It's a simplification of the expression that
> was in the original, that would have been better from the start.
>
> Thanks,
> Coleen
>
>>
>> Thanks,
>> David
>>
>> On 18/01/2017 8:49 AM, Coleen Phillimore wrote:
>>> I should have also sent this to hotspot-dev, since Bytecode_tableswitch
>>> is used by the compiler ci code.
>>> thanks,
>>> Coleen
>>>
>>>
>>> On 1/17/17 1:49 PM, Coleen Phillimore wrote:
>>>> Summary: simplify Bytecode_tableswitch code so windows doesn't
>>>> generate bad code for it.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>>>>
>>>> Verified generated code does not have sign extended value that is
>>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
>>>> some -Xcomp tests.
>>>>
>>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>
>
From david.holmes at oracle.com Wed Jan 18 02:57:34 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jan 2017 12:57:34 +1000
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
Message-ID: <afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
Hi Coleen,
On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>
>
> On 1/17/17 7:02 PM, David Holmes wrote:
>> Hi Coleen,
>>
>> The bug report does not explain the problem so it is unclear whether
>> this workaround is minimal. Also some commentary somewhere would be
>> useful else the bug might return inadvertently - more generally I'd
>> like to understand what other code might be impacted by this.
>
> Christian and I spent a solid week looking for the windows Visual Studio
> bug that caused this but weren't able to find it. He verified that it's
> fixed in VS2015. I think that's in the bug report. The code generated
> is in the bug report with annotations of what lines the code it was
> executing and which instructions caused the truncation and sign
> extension leading to a negative offset from the start of _bcp.
I'm not seeing that listing in the bug report. What code was generated
versus what code should have been generated is precisely what I was
looking for. And some idea of what problematic source code looks like.
> There's a small reproducer in the bug report for 8144518.
>
> I did a grep of all the "address.*-" and looked through the lines of
> code but I didn't generate windows assembly code to examine for all the
> pointer subtractions. I don't plan to do this. From the reproducer,
> there needed to be the swap_u4, even though the load that crashed was
> before the swap_u4 code. The scenario that caused this bug seems very
> specific and if it exists in any other places in the jvm, we can keep an
> eye out for it. This crash, while intermittent, was fairly consistent.
Very intermittent - so I guess we rarely hit the incorrectly compiled
code path.
> We think it's best to get this workaround into jdk 9 before ZBB since
> this bug has been seen several times, and we finally narrowed down the
> problem and don't have to close it as not reproduceable again.
>
> There is a line above the dest_offset_at code which I was going to
> remove, since it's describing code I changed, which doesn't make for a
> good comment. Any further commentary or explanation of this bug will be
> vague, since we don't have the VS compiler to debug to find the real
> problem, and won't make sense in the source code.
>
> Did you look at the code? It's a simplification of the expression that
> was in the original, that would have been better from the start.
Yes I looked at the code. AFAICS you now pass in an unaligned value and
align it internally, while previously the caller had to do the alignment
first - right? That inversion somehow bypasses the code that gets
incorrectly compiled.
Thanks,
David
-----
> Thanks,
> Coleen
>
>>
>> Thanks,
>> David
>>
>> On 18/01/2017 8:49 AM, Coleen Phillimore wrote:
>>> I should have also sent this to hotspot-dev, since Bytecode_tableswitch
>>> is used by the compiler ci code.
>>> thanks,
>>> Coleen
>>>
>>>
>>> On 1/17/17 1:49 PM, Coleen Phillimore wrote:
>>>> Summary: simplify Bytecode_tableswitch code so windows doesn't
>>>> generate bad code for it.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>>>>
>>>> Verified generated code does not have sign extended value that is
>>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
>>>> some -Xcomp tests.
>>>>
>>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>>
>>>
>
From kim.barrett at oracle.com Wed Jan 18 04:03:51 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 17 Jan 2017 23:03:51 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
<afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
Message-ID: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com>
> On Jan 17, 2017, at 9:57 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Coleen,
>
> On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>>
>>
>> On 1/17/17 7:02 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> The bug report does not explain the problem so it is unclear whether
>>> this workaround is minimal. Also some commentary somewhere would be
>>> useful else the bug might return inadvertently - more generally I'd
>>> like to understand what other code might be impacted by this.
>>
>> Christian and I spent a solid week looking for the windows Visual Studio
>> bug that caused this but weren't able to find it. He verified that it's
>> fixed in VS2015. I think that's in the bug report. The code generated
>> is in the bug report with annotations of what lines the code it was
>> executing and which instructions caused the truncation and sign
>> extension leading to a negative offset from the start of _bcp.
>
> I'm not seeing that listing in the bug report. What code was generated versus what code should have been generated is precisely what I was looking for. And some idea of what problematic source code looks like.
Some (most?) of the analysis and reproducer that Coleen is referring to are over in the duplicate
https://bugs.openjdk.java.net/browse/JDK-8171968
From david.holmes at oracle.com Wed Jan 18 04:16:49 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Jan 2017 14:16:49 +1000
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
<afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
<93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com>
Message-ID: <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com>
On 18/01/2017 2:03 PM, Kim Barrett wrote:
>> On Jan 17, 2017, at 9:57 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Coleen,
>>
>> On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>>>
>>>
>>> On 1/17/17 7:02 PM, David Holmes wrote:
>>>> Hi Coleen,
>>>>
>>>> The bug report does not explain the problem so it is unclear whether
>>>> this workaround is minimal. Also some commentary somewhere would be
>>>> useful else the bug might return inadvertently - more generally I'd
>>>> like to understand what other code might be impacted by this.
>>>
>>> Christian and I spent a solid week looking for the windows Visual Studio
>>> bug that caused this but weren't able to find it. He verified that it's
>>> fixed in VS2015. I think that's in the bug report. The code generated
>>> is in the bug report with annotations of what lines the code it was
>>> executing and which instructions caused the truncation and sign
>>> extension leading to a negative offset from the start of _bcp.
>>
>> I'm not seeing that listing in the bug report. What code was generated versus what code should have been generated is precisely what I was looking for. And some idea of what problematic source code looks like.
>
> Some (most?) of the analysis and reproducer that Coleen is referring to are over in the duplicate
> https://bugs.openjdk.java.net/browse/JDK-8171968
Ah! Thanks Kim.
Coleen: all much clearer now. Reviewed.
Thanks,
David
From coleen.phillimore at oracle.com Wed Jan 18 13:21:13 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jan 2017 08:21:13 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
<afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
<93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com>
<26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com>
Message-ID: <5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com>
On 1/17/17 11:16 PM, David Holmes wrote:
> On 18/01/2017 2:03 PM, Kim Barrett wrote:
>>> On Jan 17, 2017, at 9:57 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>> Hi Coleen,
>>>
>>> On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>>>>
>>>>
>>>> On 1/17/17 7:02 PM, David Holmes wrote:
>>>>> Hi Coleen,
>>>>>
>>>>> The bug report does not explain the problem so it is unclear whether
>>>>> this workaround is minimal. Also some commentary somewhere would be
>>>>> useful else the bug might return inadvertently - more generally I'd
>>>>> like to understand what other code might be impacted by this.
>>>>
>>>> Christian and I spent a solid week looking for the windows Visual
>>>> Studio
>>>> bug that caused this but weren't able to find it. He verified that
>>>> it's
>>>> fixed in VS2015. I think that's in the bug report. The code
>>>> generated
>>>> is in the bug report with annotations of what lines the code it was
>>>> executing and which instructions caused the truncation and sign
>>>> extension leading to a negative offset from the start of _bcp.
>>>
>>> I'm not seeing that listing in the bug report. What code was
>>> generated versus what code should have been generated is precisely
>>> what I was looking for. And some idea of what problematic source
>>> code looks like.
>>
>> Some (most?) of the analysis and reproducer that Coleen is referring
>> to are over in the duplicate
>> https://bugs.openjdk.java.net/browse/JDK-8171968
>
> Ah! Thanks Kim.
>
> Coleen: all much clearer now. Reviewed.
Thanks David. I thought I'd pointed to the other bug in my mail. I put
the analysis there because it matched the symptoms in the other bug and
I'd already started posting things in that one.
Thanks for the review.
Coleen
>
> Thanks,
> David
>
From david.holmes at oracle.com Wed Jan 18 22:44:56 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 19 Jan 2017 08:44:56 +1000
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
<afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
<93DCB66B-7F04-48FC-B44A-083293B892DE@oracle.com>
<26c3e633-567e-1e4d-9d40-9bdfb4e06fcb@oracle.com>
<5e89afa9-c461-71c8-0e23-39835cae0a7e@oracle.com>
Message-ID: <f2df2219-5f5f-9fc2-b4fb-9c9b862483a6@oracle.com>
On 18/01/2017 11:21 PM, Coleen Phillimore wrote:
>
>
> On 1/17/17 11:16 PM, David Holmes wrote:
>> On 18/01/2017 2:03 PM, Kim Barrett wrote:
>>>> On Jan 17, 2017, at 9:57 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> Hi Coleen,
>>>>
>>>> On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>>>>>
>>>>>
>>>>> On 1/17/17 7:02 PM, David Holmes wrote:
>>>>>> Hi Coleen,
>>>>>>
>>>>>> The bug report does not explain the problem so it is unclear whether
>>>>>> this workaround is minimal. Also some commentary somewhere would be
>>>>>> useful else the bug might return inadvertently - more generally I'd
>>>>>> like to understand what other code might be impacted by this.
>>>>>
>>>>> Christian and I spent a solid week looking for the windows Visual
>>>>> Studio
>>>>> bug that caused this but weren't able to find it. He verified that
>>>>> it's
>>>>> fixed in VS2015. I think that's in the bug report. The code
>>>>> generated
>>>>> is in the bug report with annotations of what lines the code it was
>>>>> executing and which instructions caused the truncation and sign
>>>>> extension leading to a negative offset from the start of _bcp.
>>>>
>>>> I'm not seeing that listing in the bug report. What code was
>>>> generated versus what code should have been generated is precisely
>>>> what I was looking for. And some idea of what problematic source
>>>> code looks like.
>>>
>>> Some (most?) of the analysis and reproducer that Coleen is referring
>>> to are over in the duplicate
>>> https://bugs.openjdk.java.net/browse/JDK-8171968
>>
>> Ah! Thanks Kim.
>>
>> Coleen: all much clearer now. Reviewed.
>
> Thanks David. I thought I'd pointed to the other bug in my mail. I put
You did - my bad - it didn't register as being a different bug report.
David
> the analysis there because it matched the symptoms in the other bug and
> I'd already started posting things in that one.
>
> Thanks for the review.
> Coleen
>>
>> Thanks,
>> David
>>
>
From coleen.phillimore at oracle.com Thu Jan 19 03:43:25 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Wed, 18 Jan 2017 22:43:25 -0500
Subject: RFR (S) 8144518: ClassVerboseTest crashes on Windows
In-Reply-To: <afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
References: <f7c0a4cc-b4ed-07ae-73e7-c5cacf5a2580@oracle.com>
<f513e486-8e39-5b64-d132-ceb144f9b977@oracle.com>
<a9690e56-ac7f-bb71-1431-e0e9e6010d68@oracle.com>
<d09af0be-a985-c6fd-bbce-cbaf1d70fd87@oracle.com>
<afda97ac-d0b3-6534-98b3-d579e6d5d5f0@oracle.com>
Message-ID: <cc71314d-2ff7-6daa-2fa4-2e382f164d7c@oracle.com>
Sorry I didn't see this. It went to the wrong folder.
On 1/17/17 9:57 PM, David Holmes wrote:
> Hi Coleen,
>
> On 18/01/2017 12:13 PM, Coleen Phillimore wrote:
>>
>>
>> On 1/17/17 7:02 PM, David Holmes wrote:
>>> Hi Coleen,
>>>
>>> The bug report does not explain the problem so it is unclear whether
>>> this workaround is minimal. Also some commentary somewhere would be
>>> useful else the bug might return inadvertently - more generally I'd
>>> like to understand what other code might be impacted by this.
>>
>> Christian and I spent a solid week looking for the windows Visual Studio
>> bug that caused this but weren't able to find it. He verified that it's
>> fixed in VS2015. I think that's in the bug report. The code generated
>> is in the bug report with annotations of what lines the code it was
>> executing and which instructions caused the truncation and sign
>> extension leading to a negative offset from the start of _bcp.
>
> I'm not seeing that listing in the bug report. What code was generated
> versus what code should have been generated is precisely what I was
> looking for. And some idea of what problematic source code looks like.
>
Kim answered this (the other bug).
>> There's a small reproducer in the bug report for 8144518.
>>
>> I did a grep of all the "address.*-" and looked through the lines of
>> code but I didn't generate windows assembly code to examine for all the
>> pointer subtractions. I don't plan to do this. From the reproducer,
>> there needed to be the swap_u4, even though the load that crashed was
>> before the swap_u4 code. The scenario that caused this bug seems very
>> specific and if it exists in any other places in the jvm, we can keep an
>> eye out for it. This crash, while intermittent, was fairly consistent.
>
> Very intermittent - so I guess we rarely hit the incorrectly compiled
> code path.
>
What happened was the addr_at(offset) went from some address
0x0000002e7fffffde to 0x0000002e8000000c where the sign bit if the lower
word was set. This was pretty rare and seemed to happen more in the
bytecodes copied into CHeap allocated memory for the compiler interface.
>> We think it's best to get this workaround into jdk 9 before ZBB since
>> this bug has been seen several times, and we finally narrowed down the
>> problem and don't have to close it as not reproduceable again.
>>
>> There is a line above the dest_offset_at code which I was going to
>> remove, since it's describing code I changed, which doesn't make for a
>> good comment. Any further commentary or explanation of this bug will be
>> vague, since we don't have the VS compiler to debug to find the real
>> problem, and won't make sense in the source code.
>>
>> Did you look at the code? It's a simplification of the expression that
>> was in the original, that would have been better from the start.
>
> Yes I looked at the code. AFAICS you now pass in an unaligned value
> and align it internally, while previously the caller had to do the
> alignment first - right? That inversion somehow bypasses the code that
> gets incorrectly compiled.
>
Yes.
Thanks,
Coleen
> Thanks,
> David
> -----
>
>> Thanks,
>> Coleen
>>
>>>
>>> Thanks,
>>> David
>>>
>>> On 18/01/2017 8:49 AM, Coleen Phillimore wrote:
>>>> I should have also sent this to hotspot-dev, since
>>>> Bytecode_tableswitch
>>>> is used by the compiler ci code.
>>>> thanks,
>>>> Coleen
>>>>
>>>>
>>>> On 1/17/17 1:49 PM, Coleen Phillimore wrote:
>>>>> Summary: simplify Bytecode_tableswitch code so windows doesn't
>>>>> generate bad code for it.
>>>>>
>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8144518.01/webrev
>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8144518
>>>>>
>>>>> Verified generated code does not have sign extended value that is
>>>>> subtracted, giving the wrong offset. Ran all rbt nightly tests. Ran
>>>>> some -Xcomp tests.
>>>>>
>>>>> See more info in bug https://bugs.openjdk.java.net/browse/JDK-8171968
>>>>>
>>>>> Thanks,
>>>>> Coleen
>>>>>
>>>>>
>>>>
>>
From kim.barrett at oracle.com Thu Jan 19 05:31:01 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Jan 2017 00:31:01 -0500
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
Message-ID: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
Please review this change to jweak to support G1.
The problem being addressed is that, when using G1, dereferencing a
jweak must ensure the obtained referent is ensured live, just as for
other weak reference types. This has always been a requirement, and
failure to do so appears to be a since-day1 G1 bug.
There are two categories of places that need to address this issue:
JNIHandles::resolve and friends, and returning a jobject from native
code to Java. In both of these places the jobject whose contained oop
is being extracted might really be a jweak. jweak is
representationally indistinguishable from jobject; jweak is just a
typedef for jobject. The documentation says a jweak can be used
anywhere a jobject is permitted, making that type equivalence
necessary for a C API. (A C++ API might be able to have distinct
types via inheritance, though would still need a method for
distinguishing them at runtime. But since JNI is a C API...).
The basic approach being taken is to "tag" jweaks by setting the low
order bit (recall that jweak == jobject == _jobject*), in order to
distinguish them from non-jweak jobjects. This tagging is only being
done when the selected GC needs the distinction, e.g. G1. This gives
us a representational difference between jobject and jweak on which to
base the different behavior, hiding that distinction behind the
existing API.
JNIHandles::resolve and friends are changed to unconditionally strip
off any potential weak tag when translating from jobject to to oop*.
That's cheaper than testing for the conditional use of tagging and
then stripping. Also stripped when deleting JNI handles.
TemplateInterpreterGenerator::generate_native_entry and
SharedRuntime::generate_native_wrapper are changed to conditionally
emit code to apply the G1 pre-barrier to the value obtained from a
jobject result, when the result is tagged as a jweak, which only
occurs when using G1.
For arm32/arm64, this required moving the g1_write_barrier_pre
definitions from InterpreterMacroAssembler to MacroAssembler. Also
moved g1_write_barrier_post, for consistency.
Note: I've not tested the aarch64 changes; I'll need someone with
access to that platform to test.
Note: I've not implemented this change for ppc or s390; I'll need
someone else to deal with those platforms. (It's been a very long
time since I wrote any ppc assembly code, and I've never seen an
s390.)
Note: I've done a minimal change for zero. Code elsewhere suggests
zero doesn't support G1, and I followed that.
And finally, JNIHandles::make_weak_global conditionally tags the
result.
CR:
https://bugs.openjdk.java.net/browse/JDK-8166188
Webrev:
http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
In addition to the above webrev, I've also included separate webrevs
for a test of this change, and for a whitebox extension needed for
that test. The whitebox extension is my in-progress work on
JDK-8169517, which is an enhancement targeted for JDK 10, and is not
part of this change. Since the test depends on that whitebox
extension, the test can't be included with the change either, and will
be deferred to JDK 10. But I'm including webrevs for both here, for
for reference by reviewers, and for testing on the platforms I don't
have access to.
http://cr.openjdk.java.net/~kbarrett/8166188/test.03/
http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/
http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/
Testing:
All hotspot jtreg tests run locally (Linux x86_64).
In particular:
- gc/TestReturnJNIWeak (new)
- runtime/SameObject (uses NewWeakGlobalRef)
Ad hoc hotspot nightly test on Oracle supported platforms. This
includes some closed tests that use NewWeakGlobalRef.
From mikael.gerdin at oracle.com Thu Jan 19 16:28:27 2017
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Thu, 19 Jan 2017 17:28:27 +0100
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
Message-ID: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
Hi Kim,
On 2017-01-19 06:31, Kim Barrett wrote:
> Please review this change to jweak to support G1.
>
> The problem being addressed is that, when using G1, dereferencing a
> jweak must ensure the obtained referent is ensured live, just as for
> other weak reference types. This has always been a requirement, and
> failure to do so appears to be a since-day1 G1 bug.
>
> There are two categories of places that need to address this issue:
> JNIHandles::resolve and friends, and returning a jobject from native
> code to Java. In both of these places the jobject whose contained oop
> is being extracted might really be a jweak. jweak is
> representationally indistinguishable from jobject; jweak is just a
> typedef for jobject. The documentation says a jweak can be used
> anywhere a jobject is permitted, making that type equivalence
> necessary for a C API. (A C++ API might be able to have distinct
> types via inheritance, though would still need a method for
> distinguishing them at runtime. But since JNI is a C API...).
>
> The basic approach being taken is to "tag" jweaks by setting the low
> order bit (recall that jweak == jobject == _jobject*), in order to
> distinguish them from non-jweak jobjects. This tagging is only being
> done when the selected GC needs the distinction, e.g. G1. This gives
> us a representational difference between jobject and jweak on which to
> base the different behavior, hiding that distinction behind the
> existing API.
>
> JNIHandles::resolve and friends are changed to unconditionally strip
> off any potential weak tag when translating from jobject to to oop*.
> That's cheaper than testing for the conditional use of tagging and
> then stripping. Also stripped when deleting JNI handles.
>
> TemplateInterpreterGenerator::generate_native_entry and
> SharedRuntime::generate_native_wrapper are changed to conditionally
> emit code to apply the G1 pre-barrier to the value obtained from a
> jobject result, when the result is tagged as a jweak, which only
> occurs when using G1.
>
> For arm32/arm64, this required moving the g1_write_barrier_pre
> definitions from InterpreterMacroAssembler to MacroAssembler. Also
> moved g1_write_barrier_post, for consistency.
>
> Note: I've not tested the aarch64 changes; I'll need someone with
> access to that platform to test.
>
> Note: I've not implemented this change for ppc or s390; I'll need
> someone else to deal with those platforms. (It's been a very long
> time since I wrote any ppc assembly code, and I've never seen an
> s390.)
>
> Note: I've done a minimal change for zero. Code elsewhere suggests
> zero doesn't support G1, and I followed that.
>
> And finally, JNIHandles::make_weak_global conditionally tags the
> result.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8166188
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
I thought a bit about this issue today and unfortunately I've uncovered
yet another location where a weak JNI handle needs to have its weak tag
cleared.
Consider the following JNI code snippet
jobject o = <...>;
jweak w = (*env)->NewWeakGlobalRef(env, o);
jobject param = w;
(*env)->CallStaticVoidMethod(env, c, id, param);
jni_CallStaticVoidMethod creates a JNI_ArgumentPusherVaArg and passes
that to jni_invoke_static in jni.cpp
jni_invoke_static creates a JavaCallArguments object and passes that to
the argument pusher and invokes
args->iterate( Fingerprinter(method).fingerprint() );
iterate calls get_object() on the args pusher which is supposed to
transfer the object parameter from the va_list in CallStaticVoidMethod
to the JavaCallArguments object.
The code to perform that transfer is this nasty piece of code:
inline void get_object() {
jobject l = va_arg(_ap, jobject);
_arguments->push_oop(Handle((oop *)l, false));
}
l here is our jweak and the code just does an unsafe cast to oop* and
even fakes a VM Handle using a special constructor in the Handle class.
In a debug build (or with -Xcheck:jni) this results in
JavaCallArguments::verify catching this bad oop using a
SignatureChekker::check_obj (sic) which uses this interesting code
snippet to verify an oop:
intptr_t v = _value[p];
if (v != 0 ) {
size_t t = (size_t)v;
bad = (t < (size_t)os::vm_page_size() ) ||
!Handle::raw_resolve((oop *)v)->is_oop_or_null(true);
In a product build we will crash at some random point in the future.
I've created a test to provoke this situation and put it at:
http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
run the test with
$ make test-hotspot-jtreg-native
Sorry for not coming up with this sooner, I just realized this problem
today.
/Mikael
>
> In addition to the above webrev, I've also included separate webrevs
> for a test of this change, and for a whitebox extension needed for
> that test. The whitebox extension is my in-progress work on
> JDK-8169517, which is an enhancement targeted for JDK 10, and is not
> part of this change. Since the test depends on that whitebox
> extension, the test can't be included with the change either, and will
> be deferred to JDK 10. But I'm including webrevs for both here, for
> for reference by reviewers, and for testing on the platforms I don't
> have access to.
>
> http://cr.openjdk.java.net/~kbarrett/8166188/test.03/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/
>
> Testing:
> All hotspot jtreg tests run locally (Linux x86_64).
> In particular:
> - gc/TestReturnJNIWeak (new)
> - runtime/SameObject (uses NewWeakGlobalRef)
>
> Ad hoc hotspot nightly test on Oracle supported platforms. This
> includes some closed tests that use NewWeakGlobalRef.
>
From kim.barrett at oracle.com Thu Jan 19 18:04:31 2017
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 19 Jan 2017 13:04:31 -0500
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
<62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
Message-ID: <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>
> Hi Kim,
>
> On 2017-01-19 06:31, Kim Barrett wrote:
>> Please review this change to jweak to support G1.
>>
>> [?]
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8166188
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>
> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared.
> Consider the following JNI code snippet
>
> [?]
> I've created a test to provoke this situation and put it at:
> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
> run the test with
> $ make test-hotspot-jtreg-native
>
> Sorry for not coming up with this sooner, I just realized this problem today.
Well, I?m happy you found it before this went out the door. Despite looking for this
sort of thing, I completely missed this one. I need to re-review casts to oop*.
From martin.doerr at sap.com Mon Jan 23 18:46:42 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 23 Jan 2017 18:46:42 +0000
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
<62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
<29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
Message-ID: <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap>
Hi everybody,
thanks for addressing this issue and for the webrev.
While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64).
Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it.
Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there?
Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early.
This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak.
I think PPC64 and the other platforms should do it the same way. The question is what's the better approach.
Best regards,
Martin
-----Original Message-----
From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett
Sent: Donnerstag, 19. Januar 2017 19:05
To: Mikael Gerdin <mikael.gerdin at oracle.com>
Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>
> Hi Kim,
>
> On 2017-01-19 06:31, Kim Barrett wrote:
>> Please review this change to jweak to support G1.
>>
>> [...]
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8166188
>>
>> Webrev:
>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>
> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared.
> Consider the following JNI code snippet
>
> [...]
> I've created a test to provoke this situation and put it at:
> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
> run the test with
> $ make test-hotspot-jtreg-native
>
> Sorry for not coming up with this sooner, I just realized this problem today.
Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*.
From jesper.wilhelmsson at oracle.com Mon Jan 23 23:12:43 2017
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 24 Jan 2017 00:12:43 +0100
Subject: ZBB next week - jdk9/hs will close
Message-ID: <d3bfd40c-1136-4d6b-0a94-dab155b6d975@oracle.com>
Hello HotSpot developers!
The next JDK 9 milestone, Zero Bug Bounce (ZBB), is getting closer. All JDK 9
bug fixes for ZBB need to be in master (jdk9/jdk9) no later than February 16.
As usual we need about two weeks to get from jdk9/hs through testing to
jdk9/jdk9. This means that the last date to push a change to jdk9/hs will be
February 1:st - Wednesday next week.
The current plan is to close jdk9/hs for all pushes in the evening of Wednesday
next week. This is done in order to allow for a few days of stabilization before
I will start the integration work on Friday next week.
The ZBB date and closing hs applies to all OpenJDK developers. Please sync with
me if you need more time for your last ZBB fixes.
For more information see the JDK 9 schedule on
http://openjdk.java.net/projects/jdk9/
Thank you for your co-operation!
/Jesper
Zero Bug Bounce (ZBB) ? The bug backlog is completely addressed. No open bug
with a fix targeted to the release is older than 24 hours, and other bugs have
been deferred to a future release.
From per.liden at oracle.com Tue Jan 24 10:49:19 2017
From: per.liden at oracle.com (Per Liden)
Date: Tue, 24 Jan 2017 11:49:19 +0100
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
Message-ID: <5ddce951-f85f-6633-d25b-5359aebe7114@oracle.com>
Hi Kim,
On 2017-01-19 06:31, Kim Barrett wrote:
> Please review this change to jweak to support G1.
>
> The problem being addressed is that, when using G1, dereferencing a
> jweak must ensure the obtained referent is ensured live, just as for
> other weak reference types. This has always been a requirement, and
> failure to do so appears to be a since-day1 G1 bug.
>
> There are two categories of places that need to address this issue:
> JNIHandles::resolve and friends, and returning a jobject from native
> code to Java. In both of these places the jobject whose contained oop
> is being extracted might really be a jweak. jweak is
> representationally indistinguishable from jobject; jweak is just a
> typedef for jobject. The documentation says a jweak can be used
> anywhere a jobject is permitted, making that type equivalence
> necessary for a C API. (A C++ API might be able to have distinct
> types via inheritance, though would still need a method for
> distinguishing them at runtime. But since JNI is a C API...).
>
> The basic approach being taken is to "tag" jweaks by setting the low
> order bit (recall that jweak == jobject == _jobject*), in order to
> distinguish them from non-jweak jobjects. This tagging is only being
> done when the selected GC needs the distinction, e.g. G1. This gives
> us a representational difference between jobject and jweak on which to
> base the different behavior, hiding that distinction behind the
> existing API.
I'd like to suggest that we always tag jweaks, regardless of which GC is
used. I can't see any performance issues to be afraid of here, but I can
see a number of advantages with a unified jweak representation/handling,
like avoiding #ifdef INCLUDE_ALL_GCS noise and reducing the number of
code paths to test/debug.
cheers,
Per
>
> JNIHandles::resolve and friends are changed to unconditionally strip
> off any potential weak tag when translating from jobject to to oop*.
> That's cheaper than testing for the conditional use of tagging and
> then stripping. Also stripped when deleting JNI handles.
>
> TemplateInterpreterGenerator::generate_native_entry and
> SharedRuntime::generate_native_wrapper are changed to conditionally
> emit code to apply the G1 pre-barrier to the value obtained from a
> jobject result, when the result is tagged as a jweak, which only
> occurs when using G1.
>
> For arm32/arm64, this required moving the g1_write_barrier_pre
> definitions from InterpreterMacroAssembler to MacroAssembler. Also
> moved g1_write_barrier_post, for consistency.
>
> Note: I've not tested the aarch64 changes; I'll need someone with
> access to that platform to test.
>
> Note: I've not implemented this change for ppc or s390; I'll need
> someone else to deal with those platforms. (It's been a very long
> time since I wrote any ppc assembly code, and I've never seen an
> s390.)
>
> Note: I've done a minimal change for zero. Code elsewhere suggests
> zero doesn't support G1, and I followed that.
>
> And finally, JNIHandles::make_weak_global conditionally tags the
> result.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8166188
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>
> In addition to the above webrev, I've also included separate webrevs
> for a test of this change, and for a whitebox extension needed for
> that test. The whitebox extension is my in-progress work on
> JDK-8169517, which is an enhancement targeted for JDK 10, and is not
> part of this change. Since the test depends on that whitebox
> extension, the test can't be included with the change either, and will
> be deferred to JDK 10. But I'm including webrevs for both here, for
> for reference by reviewers, and for testing on the platforms I don't
> have access to.
>
> http://cr.openjdk.java.net/~kbarrett/8166188/test.03/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/
>
> Testing:
> All hotspot jtreg tests run locally (Linux x86_64).
> In particular:
> - gc/TestReturnJNIWeak (new)
> - runtime/SameObject (uses NewWeakGlobalRef)
>
> Ad hoc hotspot nightly test on Oracle supported platforms. This
> includes some closed tests that use NewWeakGlobalRef.
>
From mikael.gerdin at oracle.com Tue Jan 24 14:50:04 2017
From: mikael.gerdin at oracle.com (Mikael Gerdin)
Date: Tue, 24 Jan 2017 15:50:04 +0100
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
<62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
<29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
<66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap>
Message-ID: <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com>
Hi Martin,
Thanks for taking a look at this change.
On 2017-01-23 19:46, Doerr, Martin wrote:
> Hi everybody,
>
> thanks for addressing this issue and for the webrev.
>
> While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64).
> Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it.
>
> Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there?
Can't say I know much about the result handlers in general but I get the
feeling that they are only there for the interpreter.
Are the result handlers applied to the return values of compiled native
wrappers as well?
Thanks
/Mikael
>
> Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early.
> This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak.
>
> I think PPC64 and the other platforms should do it the same way. The question is what's the better approach.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett
> Sent: Donnerstag, 19. Januar 2017 19:05
> To: Mikael Gerdin <mikael.gerdin at oracle.com>
> Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
>
>> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2017-01-19 06:31, Kim Barrett wrote:
>>> Please review this change to jweak to support G1.
>>>
>>> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8166188
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>>
>> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared.
>> Consider the following JNI code snippet
>>
>> [...]
>> I've created a test to provoke this situation and put it at:
>> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
>> run the test with
>> $ make test-hotspot-jtreg-native
>>
>> Sorry for not coming up with this sooner, I just realized this problem today.
>
> Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*.
>
From martin.doerr at sap.com Tue Jan 24 17:18:56 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Jan 2017 17:18:56 +0000
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
<62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
<29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
<66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap>
<38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com>
Message-ID: <c4b29347af544b479f6c0ecbd36ee941@DEWDFE13DE02.global.corp.sap>
Hi Mikael,
I found out how the oop result processing works on x86. I was kind of confused about it, yesterday.
The oop case just has an additional piece of code which forces the oop to be alive and visible to GC by copying it from the (possibly weak) handle to the oop result field. Later, the result handler reloads it from there.
The current PPC64 implementation doesn't need the additional piece of code, because the oop lives in the (possibly weak) handle until the result handler loads it from there.
We need to decide if we keep the PPC64 implementation or not. Not sure if it's worth porting this diff to other platforms.
Best regards,
Martin
-----Original Message-----
From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com]
Sent: Dienstag, 24. Januar 2017 15:50
To: Doerr, Martin <martin.doerr at sap.com>; Kim Barrett <kim.barrett at oracle.com>
Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
Hi Martin,
Thanks for taking a look at this change.
On 2017-01-23 19:46, Doerr, Martin wrote:
> Hi everybody,
>
> thanks for addressing this issue and for the webrev.
>
> While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64).
> Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it.
>
> Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there?
Can't say I know much about the result handlers in general but I get the feeling that they are only there for the interpreter.
Are the result handlers applied to the return values of compiled native wrappers as well?
Thanks
/Mikael
>
> Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early.
> This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak.
>
> I think PPC64 and the other platforms should do it the same way. The question is what's the better approach.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net]
> On Behalf Of Kim Barrett
> Sent: Donnerstag, 19. Januar 2017 19:05
> To: Mikael Gerdin <mikael.gerdin at oracle.com>
> Cc: s390x-port-dev at openjdk.java.net;
> ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak
> JNI handles
>
>> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2017-01-19 06:31, Kim Barrett wrote:
>>> Please review this change to jweak to support G1.
>>>
>>> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8166188
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>>
>> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared.
>> Consider the following JNI code snippet
>>
>> [...]
>> I've created a test to provoke this situation and put it at:
>> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
>> run the test with
>> $ make test-hotspot-jtreg-native
>>
>> Sorry for not coming up with this sooner, I just realized this problem today.
>
> Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*.
>
From jesper.wilhelmsson at oracle.com Tue Jan 24 19:10:46 2017
From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson)
Date: Tue, 24 Jan 2017 20:10:46 +0100
Subject: ZBB not next week - jdk9/hs will not close
In-Reply-To: <d3bfd40c-1136-4d6b-0a94-dab155b6d975@oracle.com>
References: <d3bfd40c-1136-4d6b-0a94-dab155b6d975@oracle.com>
Message-ID: <bda16455-b57e-7a53-2e5d-494763cfc8d1@oracle.com>
Hi again!
We started to think about what ZBB means and how it will be managed in
the HotSpot case where there is a two week delay between a fix being
pushed and the fix reaching master. I'm happy to say that my previous
interpretation was wrong.
The definition is that when all JDK 9 bugs created more than 5 [1] days
ago
are fixed, deferred, or in critical watch we reach ZBB.
This is a JBS measure and is unrelated to where a fix is located in our
repository structure. This means that since a bug is closed when we fix
it in hs, we are done in the ZBB point of view. We do not have to wait
for the fix to reach master.
The conclusion is that we got two more weeks of bug fixing before ZBB.
The ZBB date is the same regardless of where the fix is pushed -
February 16.
There is no need to close hs for ZBB.
Cheers,
/Jesper
[1] 5 or 7 days depending on who you listen to. I expect a few more
mails to pass before reaching a conclusion here.
On 2017-01-24 00:12, Jesper Wilhelmsson wrote:
> Hello HotSpot developers!
>
> The next JDK 9 milestone, Zero Bug Bounce (ZBB), is getting closer. All
> JDK 9 bug fixes for ZBB need to be in master (jdk9/jdk9) no later than
> February 16.
>
> As usual we need about two weeks to get from jdk9/hs through testing to
> jdk9/jdk9. This means that the last date to push a change to jdk9/hs
> will be February 1:st - Wednesday next week.
>
> The current plan is to close jdk9/hs for all pushes in the evening of
> Wednesday next week. This is done in order to allow for a few days of
> stabilization before I will start the integration work on Friday next week.
>
> The ZBB date and closing hs applies to all OpenJDK developers. Please
> sync with me if you need more time for your last ZBB fixes.
>
> For more information see the JDK 9 schedule on
> http://openjdk.java.net/projects/jdk9/
>
> Thank you for your co-operation!
> /Jesper
>
>
> Zero Bug Bounce (ZBB) ? The bug backlog is completely addressed. No open
> bug with a fix targeted to the release is older than 24 hours, and other
> bugs have been deferred to a future release.
From michael.rasmussen at zeroturnaround.com Thu Jan 26 12:26:20 2017
From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen)
Date: Thu, 26 Jan 2017 14:26:20 +0200
Subject: try/catch around constructor super.<init> (after 8167104)
Message-ID: <CAPMkJWYX+VDJT33oH+zLJGddajuYPKgpSd8g-A1T5ithr-b9aw@mail.gmail.com>
Hi
After the fix[1] for 8167104, it is no longer possible to have a
try/catch around the super <init> invocation, since flags are compared
as well, but verify_exception_handler_targets is called with this_uninit
set and with type resolved.
The fix broke around/tracing adapters for constructors.
previously something like this worked well:
frame[{uninitialized_this}, {}]
try
aload_0
invokespecial super.<init>
/* body */
return
end try
frame[{top}, {Throwable}]
catch
athrow
Looking at the JVMS, the above do violate the stack frame verification,
stating subset(Flags1, Flags2), which the patch fixed.
But modifying the above code to the below also fails:
frame[{uninitialized_this}, {}]
try #1
aload_0
invokespecial super.<init>
end try #1
try #2 // frame[{this}, {}]
/* body */
return
end try #2
frame[{uninitialized_this}, {Throwable}]
catch #1
athrow
frame[{top}, {Throwable}]
catch #2
athrow
Based on a quick peek, it seems when verifying the invokespecial opcode
that verify_exception_handler_targets is called inside verify_invoke_init
before the type is resolved using initialize_object, including a comment
that states that it should be done here before initialize_object. But,
verify_exception_handler_targets is called again, after initialize_object
has changed the type, from after the switch-block in verify_method, with
this_uninit set to true.
This causes an error, with the following details:
VerifyError: Stack map does not match the one at exception handler 6
Exception Details:
Location:
com/test/TraceConstructor.<init>()V @6: athrow
Reason:
Type 'com/test/TraceConstructor' (current frame, locals[0]) is not
assignable to uninitializedThis (stack map, locals[0])
Current Frame:
bci: @1
flags: { flagThisUninit }
locals: { 'com/test/TraceConstructor' }
stack: { 'java/lang/Throwable' }
Stackmap Frame:
bci: @6
flags: { flagThisUninit }
locals: { uninitializedThis }
stack: { 'java/lang/Throwable' }
Bytecode:
0x0000000: 2ab7 0008 b1bf bf
Exception Handler Table:
bci [4, 5] => handler: 5
bci [0, 4] => handler: 6
Stackmap Table:
same_frame(@0)
full_frame(@5,{Top},{Object[#10]})
full_frame(@6,{UninitializedThis},{Object[#10]})
Kind regards
Michael Rasmussen
ZeroTurnaround
[1] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/02a3d0dcbedd
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a9fdfd55835e
From harold.seigel at oracle.com Thu Jan 26 20:59:32 2017
From: harold.seigel at oracle.com (harold seigel)
Date: Thu, 26 Jan 2017 15:59:32 -0500
Subject: try/catch around constructor super.<init> (after 8167104)
In-Reply-To: <CAPMkJWYX+VDJT33oH+zLJGddajuYPKgpSd8g-A1T5ithr-b9aw@mail.gmail.com>
References: <CAPMkJWYX+VDJT33oH+zLJGddajuYPKgpSd8g-A1T5ithr-b9aw@mail.gmail.com>
Message-ID: <6d6fc85b-ad38-6f92-3ede-85dfe1640298@oracle.com>
Hi Michael,
Thank you for your email.
It is no longer possible to have an exception handler that covers
"invokespecial <init>" because of integrity reasons.
Please contact Alex Buckley (JVM Spec lead) directly at
alex.buckley at oracle.com if you have follow up questions concerning this
issue.
Thanks, Harold
On 1/26/2017 7:26 AM, Michael Rasmussen wrote:
> Hi
>
> After the fix[1] for 8167104, it is no longer possible to have a
> try/catch around the super <init> invocation, since flags are compared
> as well, but verify_exception_handler_targets is called with this_uninit
> set and with type resolved.
>
> The fix broke around/tracing adapters for constructors.
>
> previously something like this worked well:
> frame[{uninitialized_this}, {}]
> try
> aload_0
> invokespecial super.<init>
> /* body */
> return
> end try
>
> frame[{top}, {Throwable}]
> catch
> athrow
>
> Looking at the JVMS, the above do violate the stack frame verification,
> stating subset(Flags1, Flags2), which the patch fixed.
>
> But modifying the above code to the below also fails:
> frame[{uninitialized_this}, {}]
> try #1
> aload_0
> invokespecial super.<init>
> end try #1
> try #2 // frame[{this}, {}]
> /* body */
> return
> end try #2
>
> frame[{uninitialized_this}, {Throwable}]
> catch #1
> athrow
>
> frame[{top}, {Throwable}]
> catch #2
> athrow
>
> Based on a quick peek, it seems when verifying the invokespecial opcode
> that verify_exception_handler_targets is called inside verify_invoke_init
> before the type is resolved using initialize_object, including a comment
> that states that it should be done here before initialize_object. But,
> verify_exception_handler_targets is called again, after initialize_object
> has changed the type, from after the switch-block in verify_method, with
> this_uninit set to true.
>
> This causes an error, with the following details:
> VerifyError: Stack map does not match the one at exception handler 6
>
> Exception Details:
> Location:
> com/test/TraceConstructor.<init>()V @6: athrow
> Reason:
> Type 'com/test/TraceConstructor' (current frame, locals[0]) is not
> assignable to uninitializedThis (stack map, locals[0])
> Current Frame:
> bci: @1
> flags: { flagThisUninit }
> locals: { 'com/test/TraceConstructor' }
> stack: { 'java/lang/Throwable' }
> Stackmap Frame:
> bci: @6
> flags: { flagThisUninit }
> locals: { uninitializedThis }
> stack: { 'java/lang/Throwable' }
> Bytecode:
> 0x0000000: 2ab7 0008 b1bf bf
> Exception Handler Table:
> bci [4, 5] => handler: 5
> bci [0, 4] => handler: 6
> Stackmap Table:
> same_frame(@0)
> full_frame(@5,{Top},{Object[#10]})
> full_frame(@6,{UninitializedThis},{Object[#10]})
>
> Kind regards
> Michael Rasmussen
> ZeroTurnaround
>
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/02a3d0dcbedd
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a9fdfd55835e
From brent.christian at oracle.com Fri Jan 27 01:07:09 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 26 Jan 2017 17:07:09 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
Message-ID: <588A9D3D.1040200@oracle.com>
Hi,
Please review my updated approach for fixing 8156073 ("2-slot
LiveStackFrame locals (long and double) are incorrect") in the
experimental portion of the StackWalker API, added in JDK 9.
Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
(For reference, the earlier RFR thread is here:[1].)
We've concluded that we can't get enough primitive type info from the VM
to use the current fine-grain *Primitive classes in LiveStackFrameInfo,
so those classes have been removed for now. I've simplified down to
just a PrimitiveSlot32 for 32-bit VMs, and PrimitiveSlot64 for 64-bit VMs.
We also do not attempt to interpret a primitive's type based on the
slot's contents, and instead return the slot's full contents for every
primitive local. This more accurately reflects the underlying layout of
locals in the VM (versus the previous proposed
LiveStackFrame.getLocals() behavior of having 64-bit behave like 32-bit
by splitting long/double values into two slots). On the 64-bit VM, this
returns 64-bits even for primitive local variables smaller than 64-bits
(int, etc).
The upshot is that we now return the entire value for longs/doubles on
64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
I also now indicate in LiveStackFrameInfo.toString() if the frame is
interpreted or compiled.
On the testing front:
In the interest of simplifying LiveStackFrame testing down into a single
test file under jdk/test/, I chose not to add the additional test case
from Fabio Tudone [2,3] (thanks, Fabio!), but instead incorporated some
of those testing ideas into the existing test. Testing is a bit relaxed
versus the previously proposed test case; in particular it does not
enforce endianness.
I also removed the more simplistic CountLocalSlots.java test, given that
the updated LocalsAndOperands.java will now better cover testing -Xcomp.
On the hotspot side, I had to update the 8163014 regtest.
Automated test runs have looked fine so far.
Thanks,
-Brent
1.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
2.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
3. https://bugs.openjdk.java.net/browse/JDK-8158879
From david.holmes at oracle.com Fri Jan 27 05:13:53 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 27 Jan 2017 15:13:53 +1000
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need to be
removed and related tests updated
Message-ID: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
When we try to bump the JDK version to 10 we trigger all the warnings
(and an assert) surrounding the VM deprecated/obsolete/expired flag
handling. In short anything that expires in 10 must now be removed;
anything now obsolete in 10 must go in a different table. Related
changes required to source code and tests. Gory details below.
webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
Testing: JPRT (in progress)
Manual runs of affected regression tests
This will be pushed to jdk10/jdk10 along with the actual change to bump
the major version number.
There are some Zero and Aarch64 code tweaks that should have been
handled in JDK 9 but got overlooked somehow. Nothing significant.
Thanks,
David
---
Non-aliased flags:
AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
completely from the source code.
UseAutoGCSelectPolicy (def: false) has now expired and is removed
completely from the source code as-if replaced by false.
UseParNewGC (def: false) expired. However it is expected/required to be
true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC has not
been deprecated. So we must remove all uses as-if it were true, not false.
ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
expired and is removed completely from the source as-if replaced by false.
ConvertSleepToYield (def: true) is now obsolete. It is moved to the
obsolete table and is removed completely from the source code as-if
replaced by true.
ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
obsolete table and is removed completely from the source code as-if
replaced by false.
As a result of the above MinSleepInterval is no longer used (it should
have also been deprecated in 9) and is also marked as obsolete.
---
Aliased options that have expired:
CMSMarkStackSizeMax is an alias and has expired. It is removed from the
alias and obsolete flag tables.
CMSMarkStackSize is an alias and has expired. It is removed from the
alias and obsolete flag tables.
G1MarkStackSize is an alias and has expired. It is removed from the
alias and obsolete flag tables.
ParallelMarkingThreads is an alias and has expired. It is removed from
the alias and obsolete flag tables.
ParallelCMSThreads is an alias and has expired. It is removed from the
alias and obsolete flag tables.
---
The following flags all expire in 10 and exist (except where noted) only
in the special-flag table (from which they are now removed). Any other
uses of the flag are removed.
UseOldInlining
SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
UseBoundThreads (comments in os_solaris.cpp)
DefaultThreadPriority
NoYieldsInMicrolock
BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
UseNewReflection
ReflectionWrapResolutionErrors
VerifyReflectionBytecodes
AutoShutdownNMT
NmethodSweepFraction
NmethodSweepCheckInterval
CodeCacheMinimumFreeSpace
UseFastAccessorMethods (ZERO) (still used in
ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
UseFastEmptyMethods (ZERO) (still used in
ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
UseCompilerSafepoints
AdaptiveSizePausePolicy
ParallelGCRetainPLAB
ThreadSafetyMargin
LazyBootClassLoader
StarvationMonitorInterval
PreInflateSpin
JNIDetachReleasesMonitors
UseAltSigs
SegmentedHeapDumpThreshold
PrintOopAddress (comment in method.cpp)
PermSize
MaxPermSize
---
Tests modified:
runtime/CommandLine/
ObsoleteFlagErrorMessage.java
VMDeprecatedOptions.java
VMAliasOptions.java
gc/arguments/TestSelectDefaultGC.java
---
Tests removed (TEST.groups updated as needed):
gc/startup_warnings/
TestUseAutoGCSelectPolicy.java
TestParNewSerialOld.java
TestParNewCMS.java
TestDefNewCMS.java
gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
runtime/CommandLine/PermGenFlagsTest.java
runtime/NMT/AutoshutdownNMT.java
From aph at redhat.com Fri Jan 27 09:53:48 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Jan 2017 09:53:48 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
Message-ID: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
Yesterday I found an absolute doozy of a bug: we're only comparing 32
bits of an address with null. So a couple of times in a billion, if
the heap is in the right place and the moon is in the right phase, a
null pointer comparison will result in a false positive.
http://cr.openjdk.java.net/~aph/8173472-1/
Andrew.
From forax at univ-mlv.fr Fri Jan 27 10:19:34 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 27 Jan 2017 11:19:34 +0100 (CET)
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
are incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
Message-ID: <784291281.1854428.1485512374424.JavaMail.zimbra@u-pem.fr>
Hi Brent,
in LiveStackFrame, PrimitiveSlot.size() should be public.
The other solution is to see PrimitiveValue as a technical factorisation of code, not something users should know, so it should be a public class but a package-private abstract class and PrimitiveSlot32/PrimitiveSlot64 should be public (so you can try to make them value types in 10).
in LiveStackFrameInfo, the two flags MODE_* are not declared final.
cheers,
R?mi
----- Mail original -----
> De: "Brent Christian" <brent.christian at oracle.com>
> ?: "hotspot-dev" <hotspot-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "Fabio Tudone (fabio at paralleluniverse.co)" <fabio at paralleluniverse.co>
> Envoy?: Vendredi 27 Janvier 2017 02:07:09
> Objet: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are incorrect (updated)
> Hi,
>
> Please review my updated approach for fixing 8156073 ("2-slot
> LiveStackFrame locals (long and double) are incorrect") in the
> experimental portion of the StackWalker API, added in JDK 9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>
> (For reference, the earlier RFR thread is here:[1].)
>
> We've concluded that we can't get enough primitive type info from the VM
> to use the current fine-grain *Primitive classes in LiveStackFrameInfo,
> so those classes have been removed for now. I've simplified down to
> just a PrimitiveSlot32 for 32-bit VMs, and PrimitiveSlot64 for 64-bit VMs.
>
> We also do not attempt to interpret a primitive's type based on the
> slot's contents, and instead return the slot's full contents for every
> primitive local. This more accurately reflects the underlying layout of
> locals in the VM (versus the previous proposed
> LiveStackFrame.getLocals() behavior of having 64-bit behave like 32-bit
> by splitting long/double values into two slots). On the 64-bit VM, this
> returns 64-bits even for primitive local variables smaller than 64-bits
> (int, etc).
>
> The upshot is that we now return the entire value for longs/doubles on
> 64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
>
> I also now indicate in LiveStackFrameInfo.toString() if the frame is
> interpreted or compiled.
>
> On the testing front:
> In the interest of simplifying LiveStackFrame testing down into a single
> test file under jdk/test/, I chose not to add the additional test case
> from Fabio Tudone [2,3] (thanks, Fabio!), but instead incorporated some
> of those testing ideas into the existing test. Testing is a bit relaxed
> versus the previously proposed test case; in particular it does not
> enforce endianness.
>
> I also removed the more simplistic CountLocalSlots.java test, given that
> the updated LocalsAndOperands.java will now better cover testing -Xcomp.
> On the hotspot side, I had to update the 8163014 regtest.
>
> Automated test runs have looked fine so far.
>
> Thanks,
> -Brent
>
> 1.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
> 2.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
From stuart.monteith at linaro.org Fri Jan 27 11:17:03 2017
From: stuart.monteith at linaro.org (Stuart Monteith)
Date: Fri, 27 Jan 2017 11:17:03 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
Message-ID: <CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
I'm probably missing some knowledge, but this code looks a little
inconsistent from a superficial reading of the code:
1936 case T_ADDRESS:
1937 imm = opr2->as_constant_ptr()->as_jint();
1938 break;
should this be handled as_jlong() or should it be setting "is_32bit = true" ?
BR,
Stuart
On 27 January 2017 at 09:53, Andrew Haley <aph at redhat.com> wrote:
> Yesterday I found an absolute doozy of a bug: we're only comparing 32
> bits of an address with null. So a couple of times in a billion, if
> the heap is in the right place and the moon is in the right phase, a
> null pointer comparison will result in a false positive.
>
> http://cr.openjdk.java.net/~aph/8173472-1/
>
> Andrew.
>
From aph at redhat.com Fri Jan 27 13:36:45 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Jan 2017 13:36:45 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
Message-ID: <fde867fa-ba48-7e97-b82c-e834919a2b76@redhat.com>
On 27/01/17 11:17, Stuart Monteith wrote:
> I'm probably missing some knowledge, but this code looks a little
> inconsistent from a superficial reading of the code:
>
> 1936 case T_ADDRESS:
> 1937 imm = opr2->as_constant_ptr()->as_jint();
> 1938 break;
>
> should this be handled as_jlong() or should it be setting "is_32bit = true" ?
No. Oddly, as_jint() is used for addresses.
jint as_jint() const { type_check(T_INT, T_ADDRESS); return _value.get_jint(); }
I don't get it either, but if you look through the C1 source you'll
see that as_jint() is used consistently. Even here:
case T_ADDRESS: {
#ifdef _LP64
scope_values->append(new ConstantLongValue(c->as_jint()));
#else
scope_values->append(new ConstantIntValue(c->as_jint()));
#endif
return 1;
}
Andrew.
From lois.foltan at oracle.com Fri Jan 27 13:46:43 2017
From: lois.foltan at oracle.com (Lois Foltan)
Date: Fri, 27 Jan 2017 08:46:43 -0500
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
Message-ID: <588B4F43.4040907@oracle.com>
On 1/27/2017 12:13 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>
> When we try to bump the JDK version to 10 we trigger all the warnings
> (and an assert) surrounding the VM deprecated/obsolete/expired flag
> handling. In short anything that expires in 10 must now be removed;
> anything now obsolete in 10 must go in a different table. Related
> changes required to source code and tests. Gory details below.
>
> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>
> Testing: JPRT (in progress)
> Manual runs of affected regression tests
>
> This will be pushed to jdk10/jdk10 along with the actual change to
> bump the major version number.
>
> There are some Zero and Aarch64 code tweaks that should have been
> handled in JDK 9 but got overlooked somehow. Nothing significant.
Hi David,
This looks good. However, please do not remove PermSize and MaxPermSize
in the special flag table in src/share/vm/runtime/arguments.cpp. We
recently added these options back in JDK 9 for ease of migration, see
JDK-8167446. I would rather see these two options put back in the table
and have their expiration bumped to 11 until we decide going forward
what is the correct course of action. Feel free to enter a new JDK 10
specific bug to address the issue of these two options specifically.
Thanks,
Lois
>
> Thanks,
> David
> ---
>
> Non-aliased flags:
>
> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
> completely from the source code.
>
> UseAutoGCSelectPolicy (def: false) has now expired and is removed
> completely from the source code as-if replaced by false.
>
> UseParNewGC (def: false) expired. However it is expected/required to
> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
> has not been deprecated. So we must remove all uses as-if it were
> true, not false.
>
> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
> expired and is removed completely from the source as-if replaced by
> false.
>
> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
> obsolete table and is removed completely from the source code as-if
> replaced by true.
>
> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
> obsolete table and is removed completely from the source code as-if
> replaced by false.
>
> As a result of the above MinSleepInterval is no longer used (it should
> have also been deprecated in 9) and is also marked as obsolete.
>
> ---
>
> Aliased options that have expired:
>
> CMSMarkStackSizeMax is an alias and has expired. It is removed from
> the alias and obsolete flag tables.
>
> CMSMarkStackSize is an alias and has expired. It is removed from the
> alias and obsolete flag tables.
>
> G1MarkStackSize is an alias and has expired. It is removed from the
> alias and obsolete flag tables.
>
> ParallelMarkingThreads is an alias and has expired. It is removed from
> the alias and obsolete flag tables.
>
> ParallelCMSThreads is an alias and has expired. It is removed from the
> alias and obsolete flag tables.
>
> ---
>
> The following flags all expire in 10 and exist (except where noted)
> only in the special-flag table (from which they are now removed). Any
> other uses of the flag are removed.
>
> UseOldInlining
> SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
> UseBoundThreads (comments in os_solaris.cpp)
> DefaultThreadPriority
> NoYieldsInMicrolock
> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
> UseNewReflection
> ReflectionWrapResolutionErrors
> VerifyReflectionBytecodes
> AutoShutdownNMT
> NmethodSweepFraction
> NmethodSweepCheckInterval
> CodeCacheMinimumFreeSpace
> UseFastAccessorMethods (ZERO) (still used in
> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
> UseFastEmptyMethods (ZERO) (still used in
> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
> UseCompilerSafepoints
> AdaptiveSizePausePolicy
> ParallelGCRetainPLAB
> ThreadSafetyMargin
> LazyBootClassLoader
> StarvationMonitorInterval
> PreInflateSpin
> JNIDetachReleasesMonitors
> UseAltSigs
> SegmentedHeapDumpThreshold
> PrintOopAddress (comment in method.cpp)
> PermSize
> MaxPermSize
>
> ---
>
> Tests modified:
>
> runtime/CommandLine/
> ObsoleteFlagErrorMessage.java
> VMDeprecatedOptions.java
> VMAliasOptions.java
>
> gc/arguments/TestSelectDefaultGC.java
>
> ---
>
> Tests removed (TEST.groups updated as needed):
>
> gc/startup_warnings/
> TestUseAutoGCSelectPolicy.java
> TestParNewSerialOld.java
> TestParNewCMS.java
> TestDefNewCMS.java
> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>
> runtime/CommandLine/PermGenFlagsTest.java
> runtime/NMT/AutoshutdownNMT.java
From rwestrel at redhat.com Fri Jan 27 15:37:14 2017
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 27 Jan 2017 16:37:14 +0100
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use
32-bit instructions
In-Reply-To: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
Message-ID: <dk67f5gfr9x.fsf@rwestrel.remote.csb>
> Yesterday I found an absolute doozy of a bug: we're only comparing 32
> bits of an address with null. So a couple of times in a billion, if
> the heap is in the right place and the moon is in the right phase, a
> null pointer comparison will result in a false positive.
>
> http://cr.openjdk.java.net/~aph/8173472-1/
I must be missing something. What's wrong with:
if (type2aelembytes(opr1->type()) <= 4)
?
Roland.
From aph at redhat.com Fri Jan 27 16:02:13 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Jan 2017 16:02:13 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <dk67f5gfr9x.fsf@rwestrel.remote.csb>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<dk67f5gfr9x.fsf@rwestrel.remote.csb>
Message-ID: <4eb904b0-6bef-c194-5f5e-17dc8109e286@redhat.com>
On 27/01/17 15:37, Roland Westrelin wrote:
> I must be missing something. What's wrong with:
>
> if (type2aelembytes(opr1->type()) <= 4)
>
> ?
When compressed OOPs are in use, the type in memory is four bytes,
but we're comparing in registers.
Andrew.
From rwestrel at redhat.com Fri Jan 27 16:10:51 2017
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 27 Jan 2017 17:10:51 +0100
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <4eb904b0-6bef-c194-5f5e-17dc8109e286@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<dk67f5gfr9x.fsf@rwestrel.remote.csb>
<4eb904b0-6bef-c194-5f5e-17dc8109e286@redhat.com>
Message-ID: <1355f155-9b17-e856-e69f-38e7fd19964c@redhat.com>
>> I must be missing something. What's wrong with:
>>
>> if (type2aelembytes(opr1->type()) <= 4)
>>
>> ?
>
> When compressed OOPs are in use, the type in memory is four bytes,
> but we're comparing in registers.
So opr2->type() is T_OBJECT and opr1->type() is T_NARROWOOP?
Roland.
From mandy.chung at oracle.com Fri Jan 27 16:26:56 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 27 Jan 2017 08:26:56 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
Message-ID: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
>
> Hi,
>
> Please review my updated approach for fixing 8156073 ("2-slot
> LiveStackFrame locals (long and double) are incorrect") in the experimental portion of the StackWalker API, added in JDK 9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
3734 element->int_field_put(_mode_offset, value);
hotspot code uses 2-space indentation
stackwalk.hpp
line 96 - extra line can be removed.
I agree with Remi to make the MODE_* constants in LiveStackFrameInfo final and PrimitiveSlot::size() public.
Thanks for the good test and I want to take another look at it and get back to you.
Mandy
From martin.doerr at sap.com Fri Jan 27 16:44:02 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 27 Jan 2017 16:44:02 +0000
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <c4b29347af544b479f6c0ecbd36ee941@DEWDFE13DE02.global.corp.sap>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
<62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com>
<29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com>
<66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap>
<38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com>
<c4b29347af544b479f6c0ecbd36ee941@DEWDFE13DE02.global.corp.sap>
Message-ID: <b8e0b79e1a7a4e7098433b475b902107@DEWDFE13DE02.global.corp.sap>
Hi Kim, Mikael and all,
we have implemented the G1 barriers for PPC64 and s390 in this webrev:
http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.00/
The change just adds the barrier code. s390's template interpreter looks pretty much like Oracle's platforms, while PPC64's one loads the oop from the handle inside of the result handler. I think making platform implementations more similar is rather a topic for JDK10.
Thanks and best regards,
Martin
-----Original Message-----
From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
Sent: Dienstag, 24. Januar 2017 18:19
To: Mikael Gerdin <mikael.gerdin at oracle.com>; Kim Barrett <kim.barrett at oracle.com>
Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: RE: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
Hi Mikael,
I found out how the oop result processing works on x86. I was kind of confused about it, yesterday.
The oop case just has an additional piece of code which forces the oop to be alive and visible to GC by copying it from the (possibly weak) handle to the oop result field. Later, the result handler reloads it from there.
The current PPC64 implementation doesn't need the additional piece of code, because the oop lives in the (possibly weak) handle until the result handler loads it from there.
We need to decide if we keep the PPC64 implementation or not. Not sure if it's worth porting this diff to other platforms.
Best regards,
Martin
-----Original Message-----
From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com]
Sent: Dienstag, 24. Januar 2017 15:50
To: Doerr, Martin <martin.doerr at sap.com>; Kim Barrett <kim.barrett at oracle.com>
Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers <hotspot-dev at openjdk.java.net>
Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles
Hi Martin,
Thanks for taking a look at this change.
On 2017-01-23 19:46, Doerr, Martin wrote:
> Hi everybody,
>
> thanks for addressing this issue and for the webrev.
>
> While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64).
> Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it.
>
> Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there?
Can't say I know much about the result handlers in general but I get the feeling that they are only there for the interpreter.
Are the result handlers applied to the return values of compiled native wrappers as well?
Thanks
/Mikael
>
> Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early.
> This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak.
>
> I think PPC64 and the other platforms should do it the same way. The question is what's the better approach.
>
> Best regards,
> Martin
>
>
> -----Original Message-----
> From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net]
> On Behalf Of Kim Barrett
> Sent: Donnerstag, 19. Januar 2017 19:05
> To: Mikael Gerdin <mikael.gerdin at oracle.com>
> Cc: s390x-port-dev at openjdk.java.net;
> ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers
> <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak
> JNI handles
>
>> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin <mikael.gerdin at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 2017-01-19 06:31, Kim Barrett wrote:
>>> Please review this change to jweak to support G1.
>>>
>>> [...]
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8166188
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>>
>> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared.
>> Consider the following JNI code snippet
>>
>> [...]
>> I've created a test to provoke this situation and put it at:
>> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/
>> run the test with
>> $ make test-hotspot-jtreg-native
>>
>> Sorry for not coming up with this sooner, I just realized this problem today.
>
> Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*.
>
From aph at redhat.com Fri Jan 27 17:09:01 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Jan 2017 17:09:01 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <1355f155-9b17-e856-e69f-38e7fd19964c@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<dk67f5gfr9x.fsf@rwestrel.remote.csb>
<4eb904b0-6bef-c194-5f5e-17dc8109e286@redhat.com>
<1355f155-9b17-e856-e69f-38e7fd19964c@redhat.com>
Message-ID: <69b4353c-869a-ff40-9c9c-05a7dc83dfc6@redhat.com>
On 27/01/17 16:10, Roland Westrelin wrote:
>>> I must be missing something. What's wrong with:
>>>
>>> if (type2aelembytes(opr1->type()) <= 4)
>>>
>>> ?
>>
>> When compressed OOPs are in use, the type in memory is four bytes,
>> but we're comparing in registers.
>
> So opr2->type() is T_OBJECT and opr1->type() is T_NARROWOOP?
both T_OBJECT.
(gdb) p _type2aelembytes[T_OBJECT]
$10 = 4
_type2aelembytes[T_OBJECT] = heapOopSize;
The use of type2aelembytes was a mistake.
Andrew.
From rwestrel at redhat.com Fri Jan 27 17:23:46 2017
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 27 Jan 2017 18:23:46 +0100
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <69b4353c-869a-ff40-9c9c-05a7dc83dfc6@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<dk67f5gfr9x.fsf@rwestrel.remote.csb>
<4eb904b0-6bef-c194-5f5e-17dc8109e286@redhat.com>
<1355f155-9b17-e856-e69f-38e7fd19964c@redhat.com>
<69b4353c-869a-ff40-9c9c-05a7dc83dfc6@redhat.com>
Message-ID: <0c64e823-3b54-e4cb-ba62-e5219ab93ffa@redhat.com>
> (gdb) p _type2aelembytes[T_OBJECT]
> $10 = 4
>
> _type2aelembytes[T_OBJECT] = heapOopSize;
>
> The use of type2aelembytes was a mistake.
Ah! I was looking at the other initialization:
int _type2aelembytes[T_CONFLICT+1] = {
T_OBJECT_aelem_bytes, // T_OBJECT = 12
#ifdef _LP64
T_OBJECT_aelem_bytes = 8,
Change looks good to me.
Roland.
From brent.christian at oracle.com Fri Jan 27 17:33:49 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 27 Jan 2017 09:33:49 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
are incorrect (updated)
In-Reply-To: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
<CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
Message-ID: <588B847D.9060609@oracle.com>
On 01/27/2017 08:26 AM, Mandy Chung wrote:
>> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
>>
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>
> I agree with Remi to make the MODE_* constants in LiveStackFrameInfo final and PrimitiveSlot::size() public.
Thank you for the comments, Remi and Mandy. Webrev updated in place.
> Thanks for the good test and I want to take another look at it and get back to you.
Sounds good.
Thanks,
-Brent
From aph at redhat.com Fri Jan 27 18:00:43 2017
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Jan 2017 18:00:43 +0000
Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI
handles
In-Reply-To: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
References: <AC28B974-2D60-43E2-B206-1D621025B00B@oracle.com>
Message-ID: <9eef4368-6e2c-461a-63ac-69a42f467218@redhat.com>
On 19/01/17 05:31, Kim Barrett wrote:
> Please review this change to jweak to support G1.
>
> The problem being addressed is that, when using G1, dereferencing a
> jweak must ensure the obtained referent is ensured live, just as for
> other weak reference types. This has always been a requirement, and
> failure to do so appears to be a since-day1 G1 bug.
>
> There are two categories of places that need to address this issue:
> JNIHandles::resolve and friends, and returning a jobject from native
> code to Java. In both of these places the jobject whose contained oop
> is being extracted might really be a jweak. jweak is
> representationally indistinguishable from jobject; jweak is just a
> typedef for jobject. The documentation says a jweak can be used
> anywhere a jobject is permitted, making that type equivalence
> necessary for a C API. (A C++ API might be able to have distinct
> types via inheritance, though would still need a method for
> distinguishing them at runtime. But since JNI is a C API...).
>
> The basic approach being taken is to "tag" jweaks by setting the low
> order bit (recall that jweak == jobject == _jobject*), in order to
> distinguish them from non-jweak jobjects. This tagging is only being
> done when the selected GC needs the distinction, e.g. G1. This gives
> us a representational difference between jobject and jweak on which to
> base the different behavior, hiding that distinction behind the
> existing API.
>
> JNIHandles::resolve and friends are changed to unconditionally strip
> off any potential weak tag when translating from jobject to to oop*.
> That's cheaper than testing for the conditional use of tagging and
> then stripping. Also stripped when deleting JNI handles.
>
> TemplateInterpreterGenerator::generate_native_entry and
> SharedRuntime::generate_native_wrapper are changed to conditionally
> emit code to apply the G1 pre-barrier to the value obtained from a
> jobject result, when the result is tagged as a jweak, which only
> occurs when using G1.
>
> For arm32/arm64, this required moving the g1_write_barrier_pre
> definitions from InterpreterMacroAssembler to MacroAssembler. Also
> moved g1_write_barrier_post, for consistency.
>
> Note: I've not tested the aarch64 changes; I'll need someone with
> access to that platform to test.
>
> Note: I've not implemented this change for ppc or s390; I'll need
> someone else to deal with those platforms. (It's been a very long
> time since I wrote any ppc assembly code, and I've never seen an
> s390.)
>
> Note: I've done a minimal change for zero. Code elsewhere suggests
> zero doesn't support G1, and I followed that.
>
> And finally, JNIHandles::make_weak_global conditionally tags the
> result.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8166188
>
> Webrev:
> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/
>
> In addition to the above webrev, I've also included separate webrevs
> for a test of this change, and for a whitebox extension needed for
> that test. The whitebox extension is my in-progress work on
> JDK-8169517, which is an enhancement targeted for JDK 10, and is not
> part of this change. Since the test depends on that whitebox
> extension, the test can't be included with the change either, and will
> be deferred to JDK 10. But I'm including webrevs for both here, for
> for reference by reviewers, and for testing on the platforms I don't
> have access to.
>
> http://cr.openjdk.java.net/~kbarrett/8166188/test.03/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/
> http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/
>
> Testing:
> All hotspot jtreg tests run locally (Linux x86_64).
> In particular:
> - gc/TestReturnJNIWeak (new)
> - runtime/SameObject (uses NewWeakGlobalRef)
>
> Ad hoc hotspot nightly test on Oracle supported platforms. This
> includes some closed tests that use NewWeakGlobalRef.
>
Looks OK except for a small typo. I've done very light testing, but this
edge case is very hard to test anyway.
Missing semicolon:
@@ -1403,10 +1403,33 @@
__ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
__ cmp(t, result_handler);
__ br(Assembler::NE, no_oop);
- // retrieve result
+ // Unbox oop result, e.g. JNIHandles::resolve result.
__ pop(ltos);
__ cbz(r0, store_result);
- __ ldr(r0, Address(r0, 0));
+#if !INCLUDE_ALL_GCS
+ assert(!JNIHandles::need_tagged_jweaks(), "Unexpected configuration");
+#else
+ if (JNIHandles::need_tagged_jweaks()) {
+ Label not_weak;
+ STATIC_ASSERT(JNIHandles::weak_tag_mask == 1u);
+ __ tbz(r0, 0, not_weak); // Test for weak tag.
+ // Load from tagged jweak.
+ __ ldr(r0, Address(r0, -JNIHandles::weak_tag_value));
+ // Generate the G1 pre-barrier code to log the jweak's value.
+ assert(UseG1GC, "Unsupported use of tagged jweaks");
+ __ enter(); // Barrier may call runtime.
+ __ g1_write_barrier_pre(noreg /* obj */,
+ r0 /* pre_val */,
+ rthread /* thread */,
+ t /* tmp */,
+ true /* tosca_live */,
+ true /* expand_call */);
+ __ leave();
+ __ b(store_result);
+ __ bind(not_weak);
+ }
+#endif // INCLUDE_ALL_GCS
+ __ ldr(r0, Address(r0, 0)) // Get oop from box.
^ HERE
__ bind(store_result);
__ str(r0, Address(rfp, frame::interpreter_frame_oop_temp_offset*wordSize));
// keep stack depth as expected by pushing oop which will eventually be discarded
From brent.christian at oracle.com Fri Jan 27 19:02:20 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 27 Jan 2017 11:02:20 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
are incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com> <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> <4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com> <06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
Message-ID: <588B993C.7020805@oracle.com>
On 01/26/2017 05:07 PM, Brent Christian wrote:
>
> I also removed the more simplistic CountLocalSlots.java test, given that
> the updated LocalsAndOperands.java will now better cover testing -Xcomp.
I also noticed that we no longer need the LocalsCrash.java test. Removed.
-Brent
From david.holmes at oracle.com Mon Jan 30 01:06:40 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jan 2017 11:06:40 +1000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <fde867fa-ba48-7e97-b82c-e834919a2b76@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
<fde867fa-ba48-7e97-b82c-e834919a2b76@redhat.com>
Message-ID: <42e977b5-db0b-73fa-5ba8-a144731bad47@oracle.com>
On 27/01/2017 11:36 PM, Andrew Haley wrote:
> On 27/01/17 11:17, Stuart Monteith wrote:
>> I'm probably missing some knowledge, but this code looks a little
>> inconsistent from a superficial reading of the code:
>>
>> 1936 case T_ADDRESS:
>> 1937 imm = opr2->as_constant_ptr()->as_jint();
>> 1938 break;
>>
>> should this be handled as_jlong() or should it be setting "is_32bit = true" ?
>
> No. Oddly, as_jint() is used for addresses.
>
> jint as_jint() const { type_check(T_INT, T_ADDRESS); return _value.get_jint(); }
>
> I don't get it either, but if you look through the C1 source you'll
> see that as_jint() is used consistently. Even here:
>
> case T_ADDRESS: {
> #ifdef _LP64
> scope_values->append(new ConstantLongValue(c->as_jint()));
> #else
> scope_values->append(new ConstantIntValue(c->as_jint()));
> #endif
> return 1;
> }
IIRC C1 was 32-bit only - maybe even never officially supported on
64-bit, just as part of tiered ?? Is this code buggy or just quirky?
David
> Andrew.
>
From aph at redhat.com Mon Jan 30 11:26:18 2017
From: aph at redhat.com (Andrew Haley)
Date: Mon, 30 Jan 2017 11:26:18 +0000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <42e977b5-db0b-73fa-5ba8-a144731bad47@oracle.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
<fde867fa-ba48-7e97-b82c-e834919a2b76@redhat.com>
<42e977b5-db0b-73fa-5ba8-a144731bad47@oracle.com>
Message-ID: <3073a060-f737-64cf-7b1a-74480aca8fe5@redhat.com>
On 30/01/17 01:06, David Holmes wrote:
> IIRC C1 was 32-bit only - maybe even never officially supported on
> 64-bit, just as part of tiered ??
Um, what? Officially supported or not, it's still gotta work.
> Is this code buggy or just quirky?
Beats me. I'm not sure that T_ADDRESS can ever happen anyway in
that context. You'll see exactly the same in x86:
case T_ADDRESS: {
assert(patch_code == lir_patch_none, "no patching handled here");
__ movptr(dest->as_register(), c->as_jint());
break;
}
Perhaps this should be looked at, but it's not urgent.
Andrew.
From david.holmes at oracle.com Mon Jan 30 12:28:51 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Jan 2017 22:28:51 +1000
Subject: RFR: 8173472: AArch64: C1 comparisons with null only use 32-bit
instructions
In-Reply-To: <3073a060-f737-64cf-7b1a-74480aca8fe5@redhat.com>
References: <8b9200d0-b5f4-8441-47f4-e32a630b4f1f@redhat.com>
<CAEGA6kb5MAsDRf8M84sJUzeDLmy5FwHm3Z4EHWPBXsQiFheoQQ@mail.gmail.com>
<fde867fa-ba48-7e97-b82c-e834919a2b76@redhat.com>
<42e977b5-db0b-73fa-5ba8-a144731bad47@oracle.com>
<3073a060-f737-64cf-7b1a-74480aca8fe5@redhat.com>
Message-ID: <aa383bac-7261-72ea-badc-b584f3ac8abe@oracle.com>
On 30/01/2017 9:26 PM, Andrew Haley wrote:
> On 30/01/17 01:06, David Holmes wrote:
>> IIRC C1 was 32-bit only - maybe even never officially supported on
>> 64-bit, just as part of tiered ??
>
> Um, what? Officially supported or not, it's still gotta work.
Well that's what I'm questioning. Maybe one of the compiler folk
(Roland?) can chime in. C1 was 32-bit only but there was a proprietary
64-bit version. I don't know if OpenJDK ever supported a 64-bit C1. The
code would have to have been adapted for tiered compilation.
>> Is this code buggy or just quirky?
>
> Beats me. I'm not sure that T_ADDRESS can ever happen anyway in
> that context. You'll see exactly the same in x86:
>
> case T_ADDRESS: {
> assert(patch_code == lir_patch_none, "no patching handled here");
> __ movptr(dest->as_register(), c->as_jint());
> break;
> }
>
> Perhaps this should be looked at, but it's not urgent.
Ok. Seems odd to me.
David
> Andrew.
>
From david.holmes at oracle.com Mon Jan 30 20:37:46 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2017 06:37:46 +1000
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <588B4F43.4040907@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
Message-ID: <29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
Thanks for the Review Lois. For the public record there's a conversation
happening around what to do with the PermSize flags.
Can I please get additional Reviews - this affects code in all teams.
We need to get the JDK 10 forest buildable as JDK 10 ASAP.
Thanks,
David
On 27/01/2017 11:46 PM, Lois Foltan wrote:
>
> On 1/27/2017 12:13 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>
>> When we try to bump the JDK version to 10 we trigger all the warnings
>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>> handling. In short anything that expires in 10 must now be removed;
>> anything now obsolete in 10 must go in a different table. Related
>> changes required to source code and tests. Gory details below.
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>
>> Testing: JPRT (in progress)
>> Manual runs of affected regression tests
>>
>> This will be pushed to jdk10/jdk10 along with the actual change to
>> bump the major version number.
>>
>> There are some Zero and Aarch64 code tweaks that should have been
>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>
> Hi David,
>
> This looks good. However, please do not remove PermSize and MaxPermSize
> in the special flag table in src/share/vm/runtime/arguments.cpp. We
> recently added these options back in JDK 9 for ease of migration, see
> JDK-8167446. I would rather see these two options put back in the table
> and have their expiration bumped to 11 until we decide going forward
> what is the correct course of action. Feel free to enter a new JDK 10
> specific bug to address the issue of these two options specifically.
>
> Thanks,
> Lois
>
>>
>> Thanks,
>> David
>> ---
>>
>> Non-aliased flags:
>>
>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>> completely from the source code.
>>
>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>> completely from the source code as-if replaced by false.
>>
>> UseParNewGC (def: false) expired. However it is expected/required to
>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>> has not been deprecated. So we must remove all uses as-if it were
>> true, not false.
>>
>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>> expired and is removed completely from the source as-if replaced by
>> false.
>>
>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>> obsolete table and is removed completely from the source code as-if
>> replaced by true.
>>
>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
>> obsolete table and is removed completely from the source code as-if
>> replaced by false.
>>
>> As a result of the above MinSleepInterval is no longer used (it should
>> have also been deprecated in 9) and is also marked as obsolete.
>>
>> ---
>>
>> Aliased options that have expired:
>>
>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>> the alias and obsolete flag tables.
>>
>> CMSMarkStackSize is an alias and has expired. It is removed from the
>> alias and obsolete flag tables.
>>
>> G1MarkStackSize is an alias and has expired. It is removed from the
>> alias and obsolete flag tables.
>>
>> ParallelMarkingThreads is an alias and has expired. It is removed from
>> the alias and obsolete flag tables.
>>
>> ParallelCMSThreads is an alias and has expired. It is removed from the
>> alias and obsolete flag tables.
>>
>> ---
>>
>> The following flags all expire in 10 and exist (except where noted)
>> only in the special-flag table (from which they are now removed). Any
>> other uses of the flag are removed.
>>
>> UseOldInlining
>> SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>> UseBoundThreads (comments in os_solaris.cpp)
>> DefaultThreadPriority
>> NoYieldsInMicrolock
>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>> UseNewReflection
>> ReflectionWrapResolutionErrors
>> VerifyReflectionBytecodes
>> AutoShutdownNMT
>> NmethodSweepFraction
>> NmethodSweepCheckInterval
>> CodeCacheMinimumFreeSpace
>> UseFastAccessorMethods (ZERO) (still used in
>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>> UseFastEmptyMethods (ZERO) (still used in
>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>> UseCompilerSafepoints
>> AdaptiveSizePausePolicy
>> ParallelGCRetainPLAB
>> ThreadSafetyMargin
>> LazyBootClassLoader
>> StarvationMonitorInterval
>> PreInflateSpin
>> JNIDetachReleasesMonitors
>> UseAltSigs
>> SegmentedHeapDumpThreshold
>> PrintOopAddress (comment in method.cpp)
>> PermSize
>> MaxPermSize
>>
>> ---
>>
>> Tests modified:
>>
>> runtime/CommandLine/
>> ObsoleteFlagErrorMessage.java
>> VMDeprecatedOptions.java
>> VMAliasOptions.java
>>
>> gc/arguments/TestSelectDefaultGC.java
>>
>> ---
>>
>> Tests removed (TEST.groups updated as needed):
>>
>> gc/startup_warnings/
>> TestUseAutoGCSelectPolicy.java
>> TestParNewSerialOld.java
>> TestParNewCMS.java
>> TestDefNewCMS.java
>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>
>> runtime/CommandLine/PermGenFlagsTest.java
>> runtime/NMT/AutoshutdownNMT.java
>
From coleen.phillimore at oracle.com Mon Jan 30 22:52:06 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jan 2017 17:52:06 -0500
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <588A9D3D.1040200@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
Message-ID: <75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
Hi Brent,
I think this looks more conservative and better.
in
http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html
287 int mode = 0;
288 if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; }
289 if (_jvf->is_compiled_frame()) { mode |= MODE_COMPILED; }
The mode can't be interpreted AND compiled so the OR doesn't make sense
here. There may be other options though, so I wouldn't make these the
only cases. It should be something more like:
if (_jvf->is_interpreted_frame()) {
mode = MODE_INTERPRETED;
else if (_jvf->is_compiled_frame()) {
mode = MODE_COMPILED;
}
with no 'else' because it could be entry or runtime stub or new things
that we may eventually add, that you should probably not tell the API.
Otherwise this seems fine. I didn't see the update to test "On the
hotspot side, I had to update the 8163014 regtest. "
Please make sure JPRT -testset hotspot works with this (or check it in
that way).
Thanks,
Coleen
On 1/26/17 8:07 PM, Brent Christian wrote:
> Hi,
>
> Please review my updated approach for fixing 8156073 ("2-slot
> LiveStackFrame locals (long and double) are incorrect") in the
> experimental portion of the StackWalker API, added in JDK 9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>
> (For reference, the earlier RFR thread is here:[1].)
>
> We've concluded that we can't get enough primitive type info from the
> VM to use the current fine-grain *Primitive classes in
> LiveStackFrameInfo, so those classes have been removed for now. I've
> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
> PrimitiveSlot64 for 64-bit VMs.
>
> We also do not attempt to interpret a primitive's type based on the
> slot's contents, and instead return the slot's full contents for every
> primitive local. This more accurately reflects the underlying layout
> of locals in the VM (versus the previous proposed
> LiveStackFrame.getLocals() behavior of having 64-bit behave like
> 32-bit by splitting long/double values into two slots). On the 64-bit
> VM, this returns 64-bits even for primitive local variables smaller
> than 64-bits (int, etc).
>
> The upshot is that we now return the entire value for longs/doubles on
> 64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
>
> I also now indicate in LiveStackFrameInfo.toString() if the frame is
> interpreted or compiled.
>
> On the testing front:
> In the interest of simplifying LiveStackFrame testing down into a
> single test file under jdk/test/, I chose not to add the additional
> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
> incorporated some of those testing ideas into the existing test.
> Testing is a bit relaxed versus the previously proposed test case; in
> particular it does not enforce endianness.
>
> I also removed the more simplistic CountLocalSlots.java test, given
> that the updated LocalsAndOperands.java will now better cover testing
> -Xcomp. On the hotspot side, I had to update the 8163014 regtest.
>
> Automated test runs have looked fine so far.
>
> Thanks,
> -Brent
>
> 1.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
> 2.
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>
>
From mikael.vidstedt at oracle.com Tue Jan 31 00:12:48 2017
From: mikael.vidstedt at oracle.com (Mikael Vidstedt)
Date: Mon, 30 Jan 2017 16:12:48 -0800
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
<29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
Message-ID: <3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
Looks like the UseFastAccessorMethods and UseFastEmptyMethods are still in active use on ZERO, so they should not be removed. Apart from that it looks good.
And thanks for taking over the work!
Cheers,
Mikael
> On Jan 30, 2017, at 12:37 PM, David Holmes <david.holmes at oracle.com> wrote:
>
> Thanks for the Review Lois. For the public record there's a conversation happening around what to do with the PermSize flags.
>
> Can I please get additional Reviews - this affects code in all teams.
>
> We need to get the JDK 10 forest buildable as JDK 10 ASAP.
>
> Thanks,
> David
>
> On 27/01/2017 11:46 PM, Lois Foltan wrote:
>>
>> On 1/27/2017 12:13 AM, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>>
>>> When we try to bump the JDK version to 10 we trigger all the warnings
>>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>>> handling. In short anything that expires in 10 must now be removed;
>>> anything now obsolete in 10 must go in a different table. Related
>>> changes required to source code and tests. Gory details below.
>>>
>>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>>
>>> Testing: JPRT (in progress)
>>> Manual runs of affected regression tests
>>>
>>> This will be pushed to jdk10/jdk10 along with the actual change to
>>> bump the major version number.
>>>
>>> There are some Zero and Aarch64 code tweaks that should have been
>>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>>
>> Hi David,
>>
>> This looks good. However, please do not remove PermSize and MaxPermSize
>> in the special flag table in src/share/vm/runtime/arguments.cpp. We
>> recently added these options back in JDK 9 for ease of migration, see
>> JDK-8167446. I would rather see these two options put back in the table
>> and have their expiration bumped to 11 until we decide going forward
>> what is the correct course of action. Feel free to enter a new JDK 10
>> specific bug to address the issue of these two options specifically.
>>
>> Thanks,
>> Lois
>>
>>>
>>> Thanks,
>>> David
>>> ---
>>>
>>> Non-aliased flags:
>>>
>>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>>> completely from the source code.
>>>
>>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>>> completely from the source code as-if replaced by false.
>>>
>>> UseParNewGC (def: false) expired. However it is expected/required to
>>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>>> has not been deprecated. So we must remove all uses as-if it were
>>> true, not false.
>>>
>>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>>> expired and is removed completely from the source as-if replaced by
>>> false.
>>>
>>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>>> obsolete table and is removed completely from the source code as-if
>>> replaced by true.
>>>
>>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
>>> obsolete table and is removed completely from the source code as-if
>>> replaced by false.
>>>
>>> As a result of the above MinSleepInterval is no longer used (it should
>>> have also been deprecated in 9) and is also marked as obsolete.
>>>
>>> ---
>>>
>>> Aliased options that have expired:
>>>
>>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>>> the alias and obsolete flag tables.
>>>
>>> CMSMarkStackSize is an alias and has expired. It is removed from the
>>> alias and obsolete flag tables.
>>>
>>> G1MarkStackSize is an alias and has expired. It is removed from the
>>> alias and obsolete flag tables.
>>>
>>> ParallelMarkingThreads is an alias and has expired. It is removed from
>>> the alias and obsolete flag tables.
>>>
>>> ParallelCMSThreads is an alias and has expired. It is removed from the
>>> alias and obsolete flag tables.
>>>
>>> ---
>>>
>>> The following flags all expire in 10 and exist (except where noted)
>>> only in the special-flag table (from which they are now removed). Any
>>> other uses of the flag are removed.
>>>
>>> UseOldInlining
>>> SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>>> UseBoundThreads (comments in os_solaris.cpp)
>>> DefaultThreadPriority
>>> NoYieldsInMicrolock
>>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>>> UseNewReflection
>>> ReflectionWrapResolutionErrors
>>> VerifyReflectionBytecodes
>>> AutoShutdownNMT
>>> NmethodSweepFraction
>>> NmethodSweepCheckInterval
>>> CodeCacheMinimumFreeSpace
>>> UseFastAccessorMethods (ZERO) (still used in
>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>> UseFastEmptyMethods (ZERO) (still used in
>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>> UseCompilerSafepoints
>>> AdaptiveSizePausePolicy
>>> ParallelGCRetainPLAB
>>> ThreadSafetyMargin
>>> LazyBootClassLoader
>>> StarvationMonitorInterval
>>> PreInflateSpin
>>> JNIDetachReleasesMonitors
>>> UseAltSigs
>>> SegmentedHeapDumpThreshold
>>> PrintOopAddress (comment in method.cpp)
>>> PermSize
>>> MaxPermSize
>>>
>>> ---
>>>
>>> Tests modified:
>>>
>>> runtime/CommandLine/
>>> ObsoleteFlagErrorMessage.java
>>> VMDeprecatedOptions.java
>>> VMAliasOptions.java
>>>
>>> gc/arguments/TestSelectDefaultGC.java
>>>
>>> ---
>>>
>>> Tests removed (TEST.groups updated as needed):
>>>
>>> gc/startup_warnings/
>>> TestUseAutoGCSelectPolicy.java
>>> TestParNewSerialOld.java
>>> TestParNewCMS.java
>>> TestDefNewCMS.java
>>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>>
>>> runtime/CommandLine/PermGenFlagsTest.java
>>> runtime/NMT/AutoshutdownNMT.java
>>
From david.holmes at oracle.com Tue Jan 31 00:35:57 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2017 10:35:57 +1000
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
<29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
<3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
Message-ID: <54ec44f0-4787-c97b-d544-1ad622b7fb56@oracle.com>
Thanks for reviewing Mikael!
On 31/01/2017 10:12 AM, Mikael Vidstedt wrote:
>
> Looks like the UseFastAccessorMethods and UseFastEmptyMethods are still in active use on ZERO, so they should not be removed. Apart from that it looks good.
Good catch! Yes I have reverted the Zero changes, other than deleting
the flags from the table. So the following files no longer appear in the
webrev:
src/cpu/zero/vm/cppInterpreterGenerator_zero.cpp
src/cpu/zero/vm/globals_zero.hpp
src/share/vm/prims/jvmtiManageCapabilities.cpp
I've also changed the PermSize and MaxPermSize so that they have an
unspecified expiration version.
Webrev updated at:
http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
but I intend to push the changes as described
> And thanks for taking over the work!
Didn't know what I'd let myself in for :)
Thanks,
David
> Cheers,
> Mikael
>
>> On Jan 30, 2017, at 12:37 PM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Thanks for the Review Lois. For the public record there's a conversation happening around what to do with the PermSize flags.
>>
>> Can I please get additional Reviews - this affects code in all teams.
>>
>> We need to get the JDK 10 forest buildable as JDK 10 ASAP.
>>
>> Thanks,
>> David
>>
>> On 27/01/2017 11:46 PM, Lois Foltan wrote:
>>>
>>> On 1/27/2017 12:13 AM, David Holmes wrote:
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>>>
>>>> When we try to bump the JDK version to 10 we trigger all the warnings
>>>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>>>> handling. In short anything that expires in 10 must now be removed;
>>>> anything now obsolete in 10 must go in a different table. Related
>>>> changes required to source code and tests. Gory details below.
>>>>
>>>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>>>
>>>> Testing: JPRT (in progress)
>>>> Manual runs of affected regression tests
>>>>
>>>> This will be pushed to jdk10/jdk10 along with the actual change to
>>>> bump the major version number.
>>>>
>>>> There are some Zero and Aarch64 code tweaks that should have been
>>>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>>>
>>> Hi David,
>>>
>>> This looks good. However, please do not remove PermSize and MaxPermSize
>>> in the special flag table in src/share/vm/runtime/arguments.cpp. We
>>> recently added these options back in JDK 9 for ease of migration, see
>>> JDK-8167446. I would rather see these two options put back in the table
>>> and have their expiration bumped to 11 until we decide going forward
>>> what is the correct course of action. Feel free to enter a new JDK 10
>>> specific bug to address the issue of these two options specifically.
>>>
>>> Thanks,
>>> Lois
>>>
>>>>
>>>> Thanks,
>>>> David
>>>> ---
>>>>
>>>> Non-aliased flags:
>>>>
>>>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>>>> completely from the source code.
>>>>
>>>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>>>> completely from the source code as-if replaced by false.
>>>>
>>>> UseParNewGC (def: false) expired. However it is expected/required to
>>>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>>>> has not been deprecated. So we must remove all uses as-if it were
>>>> true, not false.
>>>>
>>>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>>>> expired and is removed completely from the source as-if replaced by
>>>> false.
>>>>
>>>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>>>> obsolete table and is removed completely from the source code as-if
>>>> replaced by true.
>>>>
>>>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
>>>> obsolete table and is removed completely from the source code as-if
>>>> replaced by false.
>>>>
>>>> As a result of the above MinSleepInterval is no longer used (it should
>>>> have also been deprecated in 9) and is also marked as obsolete.
>>>>
>>>> ---
>>>>
>>>> Aliased options that have expired:
>>>>
>>>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>>>> the alias and obsolete flag tables.
>>>>
>>>> CMSMarkStackSize is an alias and has expired. It is removed from the
>>>> alias and obsolete flag tables.
>>>>
>>>> G1MarkStackSize is an alias and has expired. It is removed from the
>>>> alias and obsolete flag tables.
>>>>
>>>> ParallelMarkingThreads is an alias and has expired. It is removed from
>>>> the alias and obsolete flag tables.
>>>>
>>>> ParallelCMSThreads is an alias and has expired. It is removed from the
>>>> alias and obsolete flag tables.
>>>>
>>>> ---
>>>>
>>>> The following flags all expire in 10 and exist (except where noted)
>>>> only in the special-flag table (from which they are now removed). Any
>>>> other uses of the flag are removed.
>>>>
>>>> UseOldInlining
>>>> SafepointPollOffset (defined in ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>>>> UseBoundThreads (comments in os_solaris.cpp)
>>>> DefaultThreadPriority
>>>> NoYieldsInMicrolock
>>>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>>>> UseNewReflection
>>>> ReflectionWrapResolutionErrors
>>>> VerifyReflectionBytecodes
>>>> AutoShutdownNMT
>>>> NmethodSweepFraction
>>>> NmethodSweepCheckInterval
>>>> CodeCacheMinimumFreeSpace
>>>> UseFastAccessorMethods (ZERO) (still used in
>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>> UseFastEmptyMethods (ZERO) (still used in
>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>> UseCompilerSafepoints
>>>> AdaptiveSizePausePolicy
>>>> ParallelGCRetainPLAB
>>>> ThreadSafetyMargin
>>>> LazyBootClassLoader
>>>> StarvationMonitorInterval
>>>> PreInflateSpin
>>>> JNIDetachReleasesMonitors
>>>> UseAltSigs
>>>> SegmentedHeapDumpThreshold
>>>> PrintOopAddress (comment in method.cpp)
>>>> PermSize
>>>> MaxPermSize
>>>>
>>>> ---
>>>>
>>>> Tests modified:
>>>>
>>>> runtime/CommandLine/
>>>> ObsoleteFlagErrorMessage.java
>>>> VMDeprecatedOptions.java
>>>> VMAliasOptions.java
>>>>
>>>> gc/arguments/TestSelectDefaultGC.java
>>>>
>>>> ---
>>>>
>>>> Tests removed (TEST.groups updated as needed):
>>>>
>>>> gc/startup_warnings/
>>>> TestUseAutoGCSelectPolicy.java
>>>> TestParNewSerialOld.java
>>>> TestParNewCMS.java
>>>> TestDefNewCMS.java
>>>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>>>
>>>> runtime/CommandLine/PermGenFlagsTest.java
>>>> runtime/NMT/AutoshutdownNMT.java
>>>
>
From david.holmes at oracle.com Tue Jan 31 00:42:18 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2017 10:42:18 +1000
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <54ec44f0-4787-c97b-d544-1ad622b7fb56@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
<29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
<3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
<54ec44f0-4787-c97b-d544-1ad622b7fb56@oracle.com>
Message-ID: <d2fa1e7e-d6cc-49da-725b-e6dab21933d0@oracle.com>
Forgot to add that I'm no longer deleting the test:
test/runtime/CommandLine/PermGenFlagsTest.java
David
On 31/01/2017 10:35 AM, David Holmes wrote:
> Thanks for reviewing Mikael!
>
> On 31/01/2017 10:12 AM, Mikael Vidstedt wrote:
>>
>> Looks like the UseFastAccessorMethods and UseFastEmptyMethods are
>> still in active use on ZERO, so they should not be removed. Apart from
>> that it looks good.
>
> Good catch! Yes I have reverted the Zero changes, other than deleting
> the flags from the table. So the following files no longer appear in the
> webrev:
>
> src/cpu/zero/vm/cppInterpreterGenerator_zero.cpp
> src/cpu/zero/vm/globals_zero.hpp
> src/share/vm/prims/jvmtiManageCapabilities.cpp
>
> I've also changed the PermSize and MaxPermSize so that they have an
> unspecified expiration version.
>
> Webrev updated at:
>
> http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
>
> but I intend to push the changes as described
>
>> And thanks for taking over the work!
>
> Didn't know what I'd let myself in for :)
>
> Thanks,
> David
>
>> Cheers,
>> Mikael
>>
>>> On Jan 30, 2017, at 12:37 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>> Thanks for the Review Lois. For the public record there's a
>>> conversation happening around what to do with the PermSize flags.
>>>
>>> Can I please get additional Reviews - this affects code in all teams.
>>>
>>> We need to get the JDK 10 forest buildable as JDK 10 ASAP.
>>>
>>> Thanks,
>>> David
>>>
>>> On 27/01/2017 11:46 PM, Lois Foltan wrote:
>>>>
>>>> On 1/27/2017 12:13 AM, David Holmes wrote:
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>>>>
>>>>> When we try to bump the JDK version to 10 we trigger all the warnings
>>>>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>>>>> handling. In short anything that expires in 10 must now be removed;
>>>>> anything now obsolete in 10 must go in a different table. Related
>>>>> changes required to source code and tests. Gory details below.
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>>>>
>>>>> Testing: JPRT (in progress)
>>>>> Manual runs of affected regression tests
>>>>>
>>>>> This will be pushed to jdk10/jdk10 along with the actual change to
>>>>> bump the major version number.
>>>>>
>>>>> There are some Zero and Aarch64 code tweaks that should have been
>>>>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>>>>
>>>> Hi David,
>>>>
>>>> This looks good. However, please do not remove PermSize and
>>>> MaxPermSize
>>>> in the special flag table in src/share/vm/runtime/arguments.cpp. We
>>>> recently added these options back in JDK 9 for ease of migration, see
>>>> JDK-8167446. I would rather see these two options put back in the
>>>> table
>>>> and have their expiration bumped to 11 until we decide going forward
>>>> what is the correct course of action. Feel free to enter a new JDK 10
>>>> specific bug to address the issue of these two options specifically.
>>>>
>>>> Thanks,
>>>> Lois
>>>>
>>>>>
>>>>> Thanks,
>>>>> David
>>>>> ---
>>>>>
>>>>> Non-aliased flags:
>>>>>
>>>>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>>>>> completely from the source code.
>>>>>
>>>>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>>>>> completely from the source code as-if replaced by false.
>>>>>
>>>>> UseParNewGC (def: false) expired. However it is expected/required to
>>>>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>>>>> has not been deprecated. So we must remove all uses as-if it were
>>>>> true, not false.
>>>>>
>>>>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>>>>> expired and is removed completely from the source as-if replaced by
>>>>> false.
>>>>>
>>>>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>>>>> obsolete table and is removed completely from the source code as-if
>>>>> replaced by true.
>>>>>
>>>>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
>>>>> obsolete table and is removed completely from the source code as-if
>>>>> replaced by false.
>>>>>
>>>>> As a result of the above MinSleepInterval is no longer used (it should
>>>>> have also been deprecated in 9) and is also marked as obsolete.
>>>>>
>>>>> ---
>>>>>
>>>>> Aliased options that have expired:
>>>>>
>>>>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>>>>> the alias and obsolete flag tables.
>>>>>
>>>>> CMSMarkStackSize is an alias and has expired. It is removed from the
>>>>> alias and obsolete flag tables.
>>>>>
>>>>> G1MarkStackSize is an alias and has expired. It is removed from the
>>>>> alias and obsolete flag tables.
>>>>>
>>>>> ParallelMarkingThreads is an alias and has expired. It is removed from
>>>>> the alias and obsolete flag tables.
>>>>>
>>>>> ParallelCMSThreads is an alias and has expired. It is removed from the
>>>>> alias and obsolete flag tables.
>>>>>
>>>>> ---
>>>>>
>>>>> The following flags all expire in 10 and exist (except where noted)
>>>>> only in the special-flag table (from which they are now removed). Any
>>>>> other uses of the flag are removed.
>>>>>
>>>>> UseOldInlining
>>>>> SafepointPollOffset (defined in
>>>>> ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>>>>> UseBoundThreads (comments in os_solaris.cpp)
>>>>> DefaultThreadPriority
>>>>> NoYieldsInMicrolock
>>>>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>>>>> UseNewReflection
>>>>> ReflectionWrapResolutionErrors
>>>>> VerifyReflectionBytecodes
>>>>> AutoShutdownNMT
>>>>> NmethodSweepFraction
>>>>> NmethodSweepCheckInterval
>>>>> CodeCacheMinimumFreeSpace
>>>>> UseFastAccessorMethods (ZERO) (still used in
>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>> UseFastEmptyMethods (ZERO) (still used in
>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>> UseCompilerSafepoints
>>>>> AdaptiveSizePausePolicy
>>>>> ParallelGCRetainPLAB
>>>>> ThreadSafetyMargin
>>>>> LazyBootClassLoader
>>>>> StarvationMonitorInterval
>>>>> PreInflateSpin
>>>>> JNIDetachReleasesMonitors
>>>>> UseAltSigs
>>>>> SegmentedHeapDumpThreshold
>>>>> PrintOopAddress (comment in method.cpp)
>>>>> PermSize
>>>>> MaxPermSize
>>>>>
>>>>> ---
>>>>>
>>>>> Tests modified:
>>>>>
>>>>> runtime/CommandLine/
>>>>> ObsoleteFlagErrorMessage.java
>>>>> VMDeprecatedOptions.java
>>>>> VMAliasOptions.java
>>>>>
>>>>> gc/arguments/TestSelectDefaultGC.java
>>>>>
>>>>> ---
>>>>>
>>>>> Tests removed (TEST.groups updated as needed):
>>>>>
>>>>> gc/startup_warnings/
>>>>> TestUseAutoGCSelectPolicy.java
>>>>> TestParNewSerialOld.java
>>>>> TestParNewCMS.java
>>>>> TestDefNewCMS.java
>>>>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>>>>
>>>>> runtime/CommandLine/PermGenFlagsTest.java
>>>>> runtime/NMT/AutoshutdownNMT.java
>>>>
>>
From david.holmes at oracle.com Tue Jan 31 00:47:43 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 31 Jan 2017 10:47:43 +1000
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <d2fa1e7e-d6cc-49da-725b-e6dab21933d0@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
<29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
<3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
<54ec44f0-4787-c97b-d544-1ad622b7fb56@oracle.com>
<d2fa1e7e-d6cc-49da-725b-e6dab21933d0@oracle.com>
Message-ID: <599f24e6-193e-a25e-dbd8-09ce2c167d25@oracle.com>
Just realized I still need a JDK 10 Reviewer to look at this.
http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
Thanks,
David
On 31/01/2017 10:42 AM, David Holmes wrote:
> Forgot to add that I'm no longer deleting the test:
>
> test/runtime/CommandLine/PermGenFlagsTest.java
>
> David
>
> On 31/01/2017 10:35 AM, David Holmes wrote:
>> Thanks for reviewing Mikael!
>>
>> On 31/01/2017 10:12 AM, Mikael Vidstedt wrote:
>>>
>>> Looks like the UseFastAccessorMethods and UseFastEmptyMethods are
>>> still in active use on ZERO, so they should not be removed. Apart from
>>> that it looks good.
>>
>> Good catch! Yes I have reverted the Zero changes, other than deleting
>> the flags from the table. So the following files no longer appear in the
>> webrev:
>>
>> src/cpu/zero/vm/cppInterpreterGenerator_zero.cpp
>> src/cpu/zero/vm/globals_zero.hpp
>> src/share/vm/prims/jvmtiManageCapabilities.cpp
>>
>> I've also changed the PermSize and MaxPermSize so that they have an
>> unspecified expiration version.
>>
>> Webrev updated at:
>>
>> http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
>>
>> but I intend to push the changes as described
>>
>>> And thanks for taking over the work!
>>
>> Didn't know what I'd let myself in for :)
>>
>> Thanks,
>> David
>>
>>> Cheers,
>>> Mikael
>>>
>>>> On Jan 30, 2017, at 12:37 PM, David Holmes <david.holmes at oracle.com>
>>>> wrote:
>>>>
>>>> Thanks for the Review Lois. For the public record there's a
>>>> conversation happening around what to do with the PermSize flags.
>>>>
>>>> Can I please get additional Reviews - this affects code in all teams.
>>>>
>>>> We need to get the JDK 10 forest buildable as JDK 10 ASAP.
>>>>
>>>> Thanks,
>>>> David
>>>>
>>>> On 27/01/2017 11:46 PM, Lois Foltan wrote:
>>>>>
>>>>> On 1/27/2017 12:13 AM, David Holmes wrote:
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>>>>>
>>>>>> When we try to bump the JDK version to 10 we trigger all the warnings
>>>>>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>>>>>> handling. In short anything that expires in 10 must now be removed;
>>>>>> anything now obsolete in 10 must go in a different table. Related
>>>>>> changes required to source code and tests. Gory details below.
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>>>>>
>>>>>> Testing: JPRT (in progress)
>>>>>> Manual runs of affected regression tests
>>>>>>
>>>>>> This will be pushed to jdk10/jdk10 along with the actual change to
>>>>>> bump the major version number.
>>>>>>
>>>>>> There are some Zero and Aarch64 code tweaks that should have been
>>>>>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>>>>>
>>>>> Hi David,
>>>>>
>>>>> This looks good. However, please do not remove PermSize and
>>>>> MaxPermSize
>>>>> in the special flag table in src/share/vm/runtime/arguments.cpp. We
>>>>> recently added these options back in JDK 9 for ease of migration, see
>>>>> JDK-8167446. I would rather see these two options put back in the
>>>>> table
>>>>> and have their expiration bumped to 11 until we decide going forward
>>>>> what is the correct course of action. Feel free to enter a new JDK 10
>>>>> specific bug to address the issue of these two options specifically.
>>>>>
>>>>> Thanks,
>>>>> Lois
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> ---
>>>>>>
>>>>>> Non-aliased flags:
>>>>>>
>>>>>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>>>>>> completely from the source code.
>>>>>>
>>>>>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>>>>>> completely from the source code as-if replaced by false.
>>>>>>
>>>>>> UseParNewGC (def: false) expired. However it is expected/required to
>>>>>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>>>>>> has not been deprecated. So we must remove all uses as-if it were
>>>>>> true, not false.
>>>>>>
>>>>>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>>>>>> expired and is removed completely from the source as-if replaced by
>>>>>> false.
>>>>>>
>>>>>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>>>>>> obsolete table and is removed completely from the source code as-if
>>>>>> replaced by true.
>>>>>>
>>>>>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to the
>>>>>> obsolete table and is removed completely from the source code as-if
>>>>>> replaced by false.
>>>>>>
>>>>>> As a result of the above MinSleepInterval is no longer used (it
>>>>>> should
>>>>>> have also been deprecated in 9) and is also marked as obsolete.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Aliased options that have expired:
>>>>>>
>>>>>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>>>>>> the alias and obsolete flag tables.
>>>>>>
>>>>>> CMSMarkStackSize is an alias and has expired. It is removed from the
>>>>>> alias and obsolete flag tables.
>>>>>>
>>>>>> G1MarkStackSize is an alias and has expired. It is removed from the
>>>>>> alias and obsolete flag tables.
>>>>>>
>>>>>> ParallelMarkingThreads is an alias and has expired. It is removed
>>>>>> from
>>>>>> the alias and obsolete flag tables.
>>>>>>
>>>>>> ParallelCMSThreads is an alias and has expired. It is removed from
>>>>>> the
>>>>>> alias and obsolete flag tables.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> The following flags all expire in 10 and exist (except where noted)
>>>>>> only in the special-flag table (from which they are now removed). Any
>>>>>> other uses of the flag are removed.
>>>>>>
>>>>>> UseOldInlining
>>>>>> SafepointPollOffset (defined in
>>>>>> ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>>>>>> UseBoundThreads (comments in os_solaris.cpp)
>>>>>> DefaultThreadPriority
>>>>>> NoYieldsInMicrolock
>>>>>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>>>>>> UseNewReflection
>>>>>> ReflectionWrapResolutionErrors
>>>>>> VerifyReflectionBytecodes
>>>>>> AutoShutdownNMT
>>>>>> NmethodSweepFraction
>>>>>> NmethodSweepCheckInterval
>>>>>> CodeCacheMinimumFreeSpace
>>>>>> UseFastAccessorMethods (ZERO) (still used in
>>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>>> UseFastEmptyMethods (ZERO) (still used in
>>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>>> UseCompilerSafepoints
>>>>>> AdaptiveSizePausePolicy
>>>>>> ParallelGCRetainPLAB
>>>>>> ThreadSafetyMargin
>>>>>> LazyBootClassLoader
>>>>>> StarvationMonitorInterval
>>>>>> PreInflateSpin
>>>>>> JNIDetachReleasesMonitors
>>>>>> UseAltSigs
>>>>>> SegmentedHeapDumpThreshold
>>>>>> PrintOopAddress (comment in method.cpp)
>>>>>> PermSize
>>>>>> MaxPermSize
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Tests modified:
>>>>>>
>>>>>> runtime/CommandLine/
>>>>>> ObsoleteFlagErrorMessage.java
>>>>>> VMDeprecatedOptions.java
>>>>>> VMAliasOptions.java
>>>>>>
>>>>>> gc/arguments/TestSelectDefaultGC.java
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Tests removed (TEST.groups updated as needed):
>>>>>>
>>>>>> gc/startup_warnings/
>>>>>> TestUseAutoGCSelectPolicy.java
>>>>>> TestParNewSerialOld.java
>>>>>> TestParNewCMS.java
>>>>>> TestDefNewCMS.java
>>>>>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>>>>>
>>>>>> runtime/CommandLine/PermGenFlagsTest.java
>>>>>> runtime/NMT/AutoshutdownNMT.java
>>>>>
>>>
From coleen.phillimore at oracle.com Tue Jan 31 02:47:06 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Mon, 30 Jan 2017 21:47:06 -0500
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
<75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
Message-ID: <edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
Added core-libs-dev.
Coleen
On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>
> Hi Brent,
>
> I think this looks more conservative and better.
>
> in
> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html
>
>
> 287 int mode = 0;
> 288 if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; }
> 289 if (_jvf->is_compiled_frame()) { mode |= MODE_COMPILED; }
>
> The mode can't be interpreted AND compiled so the OR doesn't make
> sense here. There may be other options though, so I wouldn't make
> these the only cases. It should be something more like:
>
> if (_jvf->is_interpreted_frame()) {
> mode = MODE_INTERPRETED;
> else if (_jvf->is_compiled_frame()) {
> mode = MODE_COMPILED;
> }
>
> with no 'else' because it could be entry or runtime stub or new things
> that we may eventually add, that you should probably not tell the API.
>
> Otherwise this seems fine. I didn't see the update to test "On the
> hotspot side, I had to update the 8163014 regtest. "
>
> Please make sure JPRT -testset hotspot works with this (or check it in
> that way).
>
> Thanks,
> Coleen
>
> On 1/26/17 8:07 PM, Brent Christian wrote:
>> Hi,
>>
>> Please review my updated approach for fixing 8156073 ("2-slot
>> LiveStackFrame locals (long and double) are incorrect") in the
>> experimental portion of the StackWalker API, added in JDK 9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>
>> (For reference, the earlier RFR thread is here:[1].)
>>
>> We've concluded that we can't get enough primitive type info from the
>> VM to use the current fine-grain *Primitive classes in
>> LiveStackFrameInfo, so those classes have been removed for now. I've
>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
>> PrimitiveSlot64 for 64-bit VMs.
>>
>> We also do not attempt to interpret a primitive's type based on the
>> slot's contents, and instead return the slot's full contents for
>> every primitive local. This more accurately reflects the underlying
>> layout of locals in the VM (versus the previous proposed
>> LiveStackFrame.getLocals() behavior of having 64-bit behave like
>> 32-bit by splitting long/double values into two slots). On the
>> 64-bit VM, this returns 64-bits even for primitive local variables
>> smaller than 64-bits (int, etc).
>>
>> The upshot is that we now return the entire value for longs/doubles
>> on 64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
>>
>> I also now indicate in LiveStackFrameInfo.toString() if the frame is
>> interpreted or compiled.
>>
>> On the testing front:
>> In the interest of simplifying LiveStackFrame testing down into a
>> single test file under jdk/test/, I chose not to add the additional
>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
>> incorporated some of those testing ideas into the existing test.
>> Testing is a bit relaxed versus the previously proposed test case; in
>> particular it does not enforce endianness.
>>
>> I also removed the more simplistic CountLocalSlots.java test, given
>> that the updated LocalsAndOperands.java will now better cover testing
>> -Xcomp. On the hotspot side, I had to update the 8163014 regtest.
>>
>> Automated test runs have looked fine so far.
>>
>> Thanks,
>> -Brent
>>
>> 1.
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
>> 2.
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>
>>
>
From kirill.zhaldybin at oracle.com Tue Jan 31 16:11:48 2017
From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin)
Date: Tue, 31 Jan 2017 19:11:48 +0300
Subject: RFR(S): 8171848: ObjectMonitor verify() and print() methods are
empty
In-Reply-To: <0f2829ac-a404-b256-41fc-0bd6d1b56656@oracle.com>
References: <585A5B15.80607@oracle.com>
<83afe5b7-abb5-a960-b92b-655284a54531@oracle.com>
<0f2829ac-a404-b256-41fc-0bd6d1b56656@oracle.com>
Message-ID: <41183671-ebd6-312d-34d4-bbde9e950f70@oracle.com>
David,
Here are a new WebRev:
http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.01/
I deleted ObjectSynchronizer::verify too since I failed to find any
calls to it.
Could you please let me know your opinion?
Thank you.
Regards, Kirill
On 21.12.2016 16:24, Kirill Zhaldybin wrote:
> David,
>
> Thank you for review!
>
> On 21.12.2016 15:46, David Holmes wrote:
>> Hi Kirill,
>>
>> This cleanup is considered an enhancement and as such is no longer
>> acceptable in JDK 9 - sorry. The CR has been re-targetted to JDK 10.
>>
>> The removal itself seems okay. I wonder whether
>> ObjectSynchronizer::verify is itself ever called?
> I did not find any calls to it but it was after I sent WebRev.
> I will double-check and will send new one if we can just delete
> ObjectSynchronizer::verify.
>
> Regards, Kirill
>>
>> David
>>
>> On 21/12/2016 8:36 PM, Kirill Zhaldybin wrote:
>>> Dear all,
>>>
>>> Could you please review this fix for 8171848?
>>> I deleted both methods from ObjectMonitor and the code which was not
>>> doing anything from ObjectSynchronizer::verify().
>>> I did local and rbt testing to be sure that I found all calls to
>>> deleted
>>> methods.
>>>
>>> WebRev:
>>> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8171848/webrev.00/
>>> CR: https://bugs.openjdk.java.net/browse/JDK-8171848
>>>
>>> Thank you.
>>>
>>> Regards, Kirill
>
From brent.christian at oracle.com Tue Jan 31 18:19:24 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 31 Jan 2017 10:19:24 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double)
are incorrect (updated)
In-Reply-To: <edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
References: <57B4C392.4060001@oracle.com> <4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com> <4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com> <06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com> <588A9D3D.1040200@oracle.com> <75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
<edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
Message-ID: <5890D52C.7010609@oracle.com>
> On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>>
>> in
>> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html
>>
>> 287 int mode = 0;
>> 288 if (_jvf->is_interpreted_frame()) { mode |= MODE_INTERPRETED; }
>> 289 if (_jvf->is_compiled_frame()) { mode |= MODE_COMPILED; }
>>
>> The mode can't be interpreted AND compiled so the OR doesn't make
>> sense here. There may be other options though, so I wouldn't make
>> these the only cases. It should be something more like:
>>
>> if (_jvf->is_interpreted_frame()) {
>> mode = MODE_INTERPRETED;
>> else if (_jvf->is_compiled_frame()) {
>> mode = MODE_COMPILED;
>> }
>>
>> with no 'else' because it could be entry or runtime stub or new things
>> that we may eventually add, that you should probably not tell the API.
Thanks - makes sense. Webrev updated in place.
>> Otherwise this seems fine. I didn't see the update to test "On the
>> hotspot side, I had to update the 8163014 regtest. "
Ah, that's this:
http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/test/runtime/LocalLong/LocalLongHelper.java.sdiff.html
though the main @test file, .../LocalLong/LocalLongTest.java, didn't
need any changes.
>> Please make sure JPRT -testset hotspot works with this (or check it in
>> that way).
Yes, that runs cleanly, and I do plan to push through hs.
Thanks for having a look, Coleen.
-Brent
>> On 1/26/17 8:07 PM, Brent Christian wrote:
>>> Hi,
>>>
>>> Please review my updated approach for fixing 8156073 ("2-slot
>>> LiveStackFrame locals (long and double) are incorrect") in the
>>> experimental portion of the StackWalker API, added in JDK 9.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>>
>>> (For reference, the earlier RFR thread is here:[1].)
>>>
>>> We've concluded that we can't get enough primitive type info from the
>>> VM to use the current fine-grain *Primitive classes in
>>> LiveStackFrameInfo, so those classes have been removed for now. I've
>>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
>>> PrimitiveSlot64 for 64-bit VMs.
>>>
>>> We also do not attempt to interpret a primitive's type based on the
>>> slot's contents, and instead return the slot's full contents for
>>> every primitive local. This more accurately reflects the underlying
>>> layout of locals in the VM (versus the previous proposed
>>> LiveStackFrame.getLocals() behavior of having 64-bit behave like
>>> 32-bit by splitting long/double values into two slots). On the
>>> 64-bit VM, this returns 64-bits even for primitive local variables
>>> smaller than 64-bits (int, etc).
>>>
>>> The upshot is that we now return the entire value for longs/doubles
>>> on 64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
>>>
>>> I also now indicate in LiveStackFrameInfo.toString() if the frame is
>>> interpreted or compiled.
>>>
>>> On the testing front:
>>> In the interest of simplifying LiveStackFrame testing down into a
>>> single test file under jdk/test/, I chose not to add the additional
>>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
>>> incorporated some of those testing ideas into the existing test.
>>> Testing is a bit relaxed versus the previously proposed test case; in
>>> particular it does not enforce endianness.
>>>
>>> I also removed the more simplistic CountLocalSlots.java test, given
>>> that the updated LocalsAndOperands.java will now better cover testing
>>> -Xcomp. On the hotspot side, I had to update the 8163014 regtest.
>>>
>>> Automated test runs have looked fine so far.
>>>
>>> Thanks,
>>> -Brent
>>>
>>> 1.
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
>>>
>>> 2.
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
>>>
>>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>>
>>>
>>
>
From mandy.chung at oracle.com Tue Jan 31 18:35:35 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 31 Jan 2017 10:35:35 -0800
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
<CEA0DB3E-AC24-4B37-8252-9E95E54CA2B3@oracle.com>
Message-ID: <3E482CA5-F97F-464A-8E67-BB797174FB13@oracle.com>
> On Jan 27, 2017, at 8:26 AM, Mandy Chung <mandy.chung at oracle.com> wrote:
>
>
>> On Jan 26, 2017, at 5:07 PM, Brent Christian <brent.christian at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review my updated approach for fixing 8156073 ("2-slot
>> LiveStackFrame locals (long and double) are incorrect") in the experimental portion of the StackWalker API, added in JDK 9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>
> :
>
> Thanks for the good test and I want to take another look at it and get back to you.
I check the updated webrev and looks good.
The test looks good and it?s updated with my suggested formatting that I sent to you offline. Thanks.
Mandy
From ioi.lam at oracle.com Tue Jan 31 20:01:29 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 31 Jan 2017 12:01:29 -0800
Subject: Easy hashtable for HotSpot
Message-ID: <5890ED19.7070600@oracle.com>
I've always been frustrated by the HotSpot hashtable code. It looks like
every time you need to create a new table, you have to write a whole
bunch of boilerplate code like get() and add(). This is especially bad
if you just need a very simple mapping.
So I've created an "Easy" hashtable, to reduce as much boilerplate code
as possible:
template <class T, class Entry, MEMFLAGS F> class EasyHashtable
: public Hashtable<T, F>
{
static unsigned int compute_hash(T key) {
return Entry::compute_hash(key);
}
int hash_to_index(unsigned int hash) {
return Hashtable<T, F>::hash_to_index(hash);
}
public:
EasyHashtable(int table_size)
: Hashtable<T, F>(table_size, sizeof(Entry)) {}
// For iterating all the entries in the table
Entry* bucket(int index) {
return (Entry*)Hashtable<T, F>::bucket(index);
}
Entry* get(T literal) {
unsigned int hash = compute_hash(literal);
int index = hash_to_index(hash);
for (Entry* e = bucket(index); e != NULL; e = (Entry*)e->next()) {
if (e->literal() == literal) {
return e;
}
}
return NULL;
}
Entry* add(T literal) {
unsigned int hash = compute_hash(literal);
int index = hash_to_index(hash);
Entry* e = (Entry*)Hashtable<T, F>::new_entry(hash, literal);
Hashtable<T, F>::add_entry(index, e);
return e;
}
};
Here's an example (map Symbol* -> Klass*). You just need to provide your
own hash function.
class SymToKlassEntry : public HashtableEntry<Symbol*, mtSymbol> {
Klass* _klass;
public:
static unsigned int compute_hash(Symbol* sym) {
return (unsigned int) sym->identity_hash();
}
void init(Klass* k) {
_klass = k;
}
Klass* klass() {
return _klass;
}
};
void test() {
typedef EasyHashtable<Symbol*, SymToKlassEntry, mtSymbol> MyTable;
MyTable* table = new MyTable(1234);
Symbol* sym = SymbolTable::new_permanent_symbol("some symbol", CHECK);
table->add(sym)->init((Klass*)0xbaadf00d);
Klass* klass = table->get(sym)->klass();
// Iterate all symbols
for (int i=0; i<table->table_size(); i++) {
for (SymToKlassEntry* entry = table->bucket(i);
entry;
entry = (SymToKlassEntry*)entry->next()) {
tty->print_cr("sym: %p => klass: %p", entry->literal(),
entry->klass());
}
}
}
}
Another common case would be to map an address to arbitrary data type.
(I needed this for fixing JDK-8072061)
template <MEMFLAGS F> class AddressHashtableEntry
: public HashtableEntry<address, F> {
public:
static unsigned int compute_hash(address obj) {
return (unsigned int)(uintptr_t(obj) >> BitsPerWord);
}
};
template <class Entry, MEMFLAGS F> class AddressHashtable
: public EasyHashtable<address, Entry, F> {
public:
AddressHashtable(int table_size)
: EasyHashtable<address, Entry, F>(table_size) {}
Entry* get(address obj) {
assert(obj != NULL, "Caller should not pass in NULL");
return (Entry*)EasyHashtable<address, Entry, mtInternal>::get(obj);
}
Entry* add(address obj) {
assert(obj != NULL, "Caller should not pass in NULL");
return (Entry*)EasyHashtable<address, Entry, mtInternal>::add(obj);
}
};
Examples:
class AddrToNumEntry : public AddressHashtableEntry<mtInternal> {
int _val;
public:
void init(int v) {
_val = v;
}
int val() {
return _val;
}
};
void test() {
// A table of known addresses
{
typedef AddressHashtableEntry<mtInternal> MyEntry;
typedef AddressHashtable<MyEntry, mtInternal> MyTable;
MyTable* table = new MyTable(1234);
table->add((address)0xdeadbeef);
tty->print_cr("exists? %d", (table->get((address)0xbaadf00d) != NULL));
tty->print_cr("exists? %d", (table->get((address)0xdeadbeef) != NULL));
}
// Map addresses to numbers
{
typedef AddressHashtable<AddrToNumEntry, mtInternal> MyTable;
MyTable* table = new MyTable(1234);
table->add((address)0xdeadbeef)->init(1);
table->add((address)0xbaadf00d)->init(2);
tty->print_cr("%d", table->get((address)0xdeadbeef)->val());
}
}
Any thoughts about this coding style?
Thanks
- Ioi
From coleen.phillimore at oracle.com Tue Jan 31 20:27:46 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 31 Jan 2017 15:27:46 -0500
Subject: RFR 8156073 : 2-slot LiveStackFrame locals (long and double) are
incorrect (updated)
In-Reply-To: <5890D52C.7010609@oracle.com>
References: <57B4C392.4060001@oracle.com>
<4FC68523-111E-4E53-8E97-A03EFC06CF47@oracle.com>
<4FB2B467-9E82-4A4C-B687-B1C61FE1FD61@oracle.com>
<06239E18-666A-4931-BD56-BBECE3EC8E86@oracle.com>
<588A9D3D.1040200@oracle.com>
<75c5a7d6-7c61-2cd0-a3a4-e0d8330e8a23@oracle.com>
<edc5fd74-2cd7-9bd6-d07a-b912bf2753d5@oracle.com>
<5890D52C.7010609@oracle.com>
Message-ID: <3bd74b91-a34d-6506-6b90-7847ebd0bdf3@oracle.com>
Thanks Brent, looks good!
Coleen
On 1/31/17 1:19 PM, Brent Christian wrote:
>> On 1/30/17 5:52 PM, Coleen Phillimore wrote:
>>>
>>> in
>>> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/src/share/vm/prims/stackwalk.cpp.html
>>>
>>>
>>> 287 int mode = 0;
>>> 288 if (_jvf->is_interpreted_frame()) { mode |=
>>> MODE_INTERPRETED; }
>>> 289 if (_jvf->is_compiled_frame()) { mode |=
>>> MODE_COMPILED; }
>>>
>>> The mode can't be interpreted AND compiled so the OR doesn't make
>>> sense here. There may be other options though, so I wouldn't make
>>> these the only cases. It should be something more like:
>>>
>>> if (_jvf->is_interpreted_frame()) {
>>> mode = MODE_INTERPRETED;
>>> else if (_jvf->is_compiled_frame()) {
>>> mode = MODE_COMPILED;
>>> }
>>>
>>> with no 'else' because it could be entry or runtime stub or new things
>>> that we may eventually add, that you should probably not tell the API.
>
> Thanks - makes sense. Webrev updated in place.
>
>>> Otherwise this seems fine. I didn't see the update to test "On the
>>> hotspot side, I had to update the 8163014 regtest. "
>
> Ah, that's this:
>
> http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/hotspot/test/runtime/LocalLong/LocalLongHelper.java.sdiff.html
>
>
> though the main @test file, .../LocalLong/LocalLongTest.java, didn't
> need any changes.
>
>>> Please make sure JPRT -testset hotspot works with this (or check it in
>>> that way).
>
> Yes, that runs cleanly, and I do plan to push through hs.
>
> Thanks for having a look, Coleen.
>
> -Brent
>
>>> On 1/26/17 8:07 PM, Brent Christian wrote:
>>>> Hi,
>>>>
>>>> Please review my updated approach for fixing 8156073 ("2-slot
>>>> LiveStackFrame locals (long and double) are incorrect") in the
>>>> experimental portion of the StackWalker API, added in JDK 9.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156073
>>>> Webrev: http://cr.openjdk.java.net/~bchristi/8156073/webrev.03/
>>>>
>>>> (For reference, the earlier RFR thread is here:[1].)
>>>>
>>>> We've concluded that we can't get enough primitive type info from the
>>>> VM to use the current fine-grain *Primitive classes in
>>>> LiveStackFrameInfo, so those classes have been removed for now. I've
>>>> simplified down to just a PrimitiveSlot32 for 32-bit VMs, and
>>>> PrimitiveSlot64 for 64-bit VMs.
>>>>
>>>> We also do not attempt to interpret a primitive's type based on the
>>>> slot's contents, and instead return the slot's full contents for
>>>> every primitive local. This more accurately reflects the underlying
>>>> layout of locals in the VM (versus the previous proposed
>>>> LiveStackFrame.getLocals() behavior of having 64-bit behave like
>>>> 32-bit by splitting long/double values into two slots). On the
>>>> 64-bit VM, this returns 64-bits even for primitive local variables
>>>> smaller than 64-bits (int, etc).
>>>>
>>>> The upshot is that we now return the entire value for longs/doubles
>>>> on 64-bit VMs. (The current JDK 9 only reads the first 32-bits.)
>>>>
>>>> I also now indicate in LiveStackFrameInfo.toString() if the frame is
>>>> interpreted or compiled.
>>>>
>>>> On the testing front:
>>>> In the interest of simplifying LiveStackFrame testing down into a
>>>> single test file under jdk/test/, I chose not to add the additional
>>>> test case from Fabio Tudone [2,3] (thanks, Fabio!), but instead
>>>> incorporated some of those testing ideas into the existing test.
>>>> Testing is a bit relaxed versus the previously proposed test case; in
>>>> particular it does not enforce endianness.
>>>>
>>>> I also removed the more simplistic CountLocalSlots.java test, given
>>>> that the updated LocalsAndOperands.java will now better cover testing
>>>> -Xcomp. On the hotspot side, I had to update the 8163014 regtest.
>>>>
>>>> Automated test runs have looked fine so far.
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> 1.
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042979.html
>>>>
>>>>
>>>> 2.
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041666.html
>>>>
>>>>
>>>> 3. https://bugs.openjdk.java.net/browse/JDK-8158879
>>>>
>>>>
>>>
>>
>
From coleen.phillimore at oracle.com Tue Jan 31 21:37:31 2017
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Tue, 31 Jan 2017 16:37:31 -0500
Subject: Easy hashtable for HotSpot
In-Reply-To: <5890ED19.7070600@oracle.com>
References: <5890ED19.7070600@oracle.com>
Message-ID: <efdee58e-668f-4028-d38b-c7470f3a6164@oracle.com>
There is also a ResourceHashTable, did you see that? We don't need an
*additional* hashtable, we just need a good one!
Coleen
On 1/31/17 3:01 PM, Ioi Lam wrote:
> I've always been frustrated by the HotSpot hashtable code. It looks
> like every time you need to create a new table, you have to write a
> whole bunch of boilerplate code like get() and add(). This is
> especially bad if you just need a very simple mapping.
>
> So I've created an "Easy" hashtable, to reduce as much boilerplate
> code as possible:
>
>
> template <class T, class Entry, MEMFLAGS F> class EasyHashtable
> : public Hashtable<T, F>
> {
> static unsigned int compute_hash(T key) {
> return Entry::compute_hash(key);
> }
> int hash_to_index(unsigned int hash) {
> return Hashtable<T, F>::hash_to_index(hash);
> }
> public:
> EasyHashtable(int table_size)
> : Hashtable<T, F>(table_size, sizeof(Entry)) {}
>
> // For iterating all the entries in the table
> Entry* bucket(int index) {
> return (Entry*)Hashtable<T, F>::bucket(index);
> }
>
> Entry* get(T literal) {
> unsigned int hash = compute_hash(literal);
> int index = hash_to_index(hash);
> for (Entry* e = bucket(index); e != NULL; e = (Entry*)e->next()) {
> if (e->literal() == literal) {
> return e;
> }
> }
> return NULL;
> }
>
> Entry* add(T literal) {
> unsigned int hash = compute_hash(literal);
> int index = hash_to_index(hash);
> Entry* e = (Entry*)Hashtable<T, F>::new_entry(hash, literal);
> Hashtable<T, F>::add_entry(index, e);
> return e;
> }
> };
>
>
> Here's an example (map Symbol* -> Klass*). You just need to provide
> your own hash function.
>
>
> class SymToKlassEntry : public HashtableEntry<Symbol*, mtSymbol> {
> Klass* _klass;
> public:
> static unsigned int compute_hash(Symbol* sym) {
> return (unsigned int) sym->identity_hash();
> }
> void init(Klass* k) {
> _klass = k;
> }
> Klass* klass() {
> return _klass;
> }
> };
>
> void test() {
> typedef EasyHashtable<Symbol*, SymToKlassEntry, mtSymbol> MyTable;
> MyTable* table = new MyTable(1234);
> Symbol* sym = SymbolTable::new_permanent_symbol("some symbol",
> CHECK);
> table->add(sym)->init((Klass*)0xbaadf00d);
> Klass* klass = table->get(sym)->klass();
>
> // Iterate all symbols
> for (int i=0; i<table->table_size(); i++) {
> for (SymToKlassEntry* entry = table->bucket(i);
> entry;
> entry = (SymToKlassEntry*)entry->next()) {
> tty->print_cr("sym: %p => klass: %p", entry->literal(),
> entry->klass());
> }
> }
> }
> }
>
>
>
>
> Another common case would be to map an address to arbitrary data type.
> (I needed this for fixing JDK-8072061)
>
>
> template <MEMFLAGS F> class AddressHashtableEntry
> : public HashtableEntry<address, F> {
> public:
> static unsigned int compute_hash(address obj) {
> return (unsigned int)(uintptr_t(obj) >> BitsPerWord);
> }
> };
>
> template <class Entry, MEMFLAGS F> class AddressHashtable
> : public EasyHashtable<address, Entry, F> {
> public:
> AddressHashtable(int table_size)
> : EasyHashtable<address, Entry, F>(table_size) {}
>
> Entry* get(address obj) {
> assert(obj != NULL, "Caller should not pass in NULL");
> return (Entry*)EasyHashtable<address, Entry, mtInternal>::get(obj);
> }
> Entry* add(address obj) {
> assert(obj != NULL, "Caller should not pass in NULL");
> return (Entry*)EasyHashtable<address, Entry, mtInternal>::add(obj);
> }
> };
>
>
> Examples:
>
>
> class AddrToNumEntry : public AddressHashtableEntry<mtInternal> {
> int _val;
> public:
> void init(int v) {
> _val = v;
> }
> int val() {
> return _val;
> }
> };
>
> void test() {
> // A table of known addresses
> {
> typedef AddressHashtableEntry<mtInternal> MyEntry;
> typedef AddressHashtable<MyEntry, mtInternal> MyTable;
> MyTable* table = new MyTable(1234);
> table->add((address)0xdeadbeef);
> tty->print_cr("exists? %d", (table->get((address)0xbaadf00d) !=
> NULL));
> tty->print_cr("exists? %d", (table->get((address)0xdeadbeef) !=
> NULL));
> }
>
> // Map addresses to numbers
> {
> typedef AddressHashtable<AddrToNumEntry, mtInternal> MyTable;
> MyTable* table = new MyTable(1234);
> table->add((address)0xdeadbeef)->init(1);
> table->add((address)0xbaadf00d)->init(2);
> tty->print_cr("%d", table->get((address)0xdeadbeef)->val());
> }
> }
>
>
> Any thoughts about this coding style?
>
> Thanks
> - Ioi
>
>
From daniel.daugherty at oracle.com Tue Jan 31 22:14:19 2017
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Tue, 31 Jan 2017 15:14:19 -0700
Subject: JDK 10 RFR: 8173421: Obsolete and expired flags for JDK 10 need
to be removed and related tests updated
In-Reply-To: <599f24e6-193e-a25e-dbd8-09ce2c167d25@oracle.com>
References: <ce46f3b7-e11d-d5a7-52c0-6f6393cd2ce6@oracle.com>
<588B4F43.4040907@oracle.com>
<29a0c6ad-ac7a-ac6f-61b9-76b63fabd94d@oracle.com>
<3253D1E0-7E1B-4C5C-967B-49B0DDB179F7@oracle.com>
<54ec44f0-4787-c97b-d544-1ad622b7fb56@oracle.com>
<d2fa1e7e-d6cc-49da-725b-e6dab21933d0@oracle.com>
<599f24e6-193e-a25e-dbd8-09ce2c167d25@oracle.com>
Message-ID: <4025f109-3f01-2a73-55f0-a12c54092708@oracle.com>
On 1/30/17 5:47 PM, David Holmes wrote:
> Just realized I still need a JDK 10 Reviewer to look at this.
>
> http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
src/cpu/aarch64/vm/c1_globals_aarch64.hpp
No comments.
src/cpu/aarch64/vm/c2_globals_aarch64.hpp
No comments.
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
No comments.
src/os/solaris/vm/os_solaris.cpp
No comments.
src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp
No comments.
src/share/vm/oops/method.cpp
No comments.
src/share/vm/prims/jvm.cpp
The JVM_Sleep() changes had me confused for second,
but I think they're okay...
No other comments.
src/share/vm/runtime/arguments.cpp
MinSleepInterval - are you going to deprecate this in JDK9?
No other comments.
src/share/vm/runtime/arguments.hpp
No comments.
src/share/vm/runtime/globals.hpp
No comments.
test/TEST.groups
No comments.
test/gc/arguments/TestSelectDefaultGC.java
No comments.
test/runtime/CommandLine/ObsoleteFlagErrorMessage.java
No comments.
test/runtime/CommandLine/VMAliasOptions.java
No comments.
test/runtime/CommandLine/VMDeprecatedOptions.java
No comments.
test/gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
test/gc/startup_warnings/TestDefNewCMS.java
test/gc/startup_warnings/TestParNewCMS.java
test/gc/startup_warnings/TestParNewSerialOld.java
test/gc/startup_warnings/TestUseAutoGCSelectPolicy.java
test/runtime/NMT/AutoshutdownNMT.java
No comments on the deleted files.
Thumbs up!
Dan
>
> Thanks,
> David
>
> On 31/01/2017 10:42 AM, David Holmes wrote:
>> Forgot to add that I'm no longer deleting the test:
>>
>> test/runtime/CommandLine/PermGenFlagsTest.java
>>
>> David
>>
>> On 31/01/2017 10:35 AM, David Holmes wrote:
>>> Thanks for reviewing Mikael!
>>>
>>> On 31/01/2017 10:12 AM, Mikael Vidstedt wrote:
>>>>
>>>> Looks like the UseFastAccessorMethods and UseFastEmptyMethods are
>>>> still in active use on ZERO, so they should not be removed. Apart from
>>>> that it looks good.
>>>
>>> Good catch! Yes I have reverted the Zero changes, other than deleting
>>> the flags from the table. So the following files no longer appear in
>>> the
>>> webrev:
>>>
>>> src/cpu/zero/vm/cppInterpreterGenerator_zero.cpp
>>> src/cpu/zero/vm/globals_zero.hpp
>>> src/share/vm/prims/jvmtiManageCapabilities.cpp
>>>
>>> I've also changed the PermSize and MaxPermSize so that they have an
>>> unspecified expiration version.
>>>
>>> Webrev updated at:
>>>
>>> http://cr.openjdk.java.net/~dholmes/8173421/webrev.hotspot.v2/
>>>
>>> but I intend to push the changes as described
>>>
>>>> And thanks for taking over the work!
>>>
>>> Didn't know what I'd let myself in for :)
>>>
>>> Thanks,
>>> David
>>>
>>>> Cheers,
>>>> Mikael
>>>>
>>>>> On Jan 30, 2017, at 12:37 PM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>>
>>>>> Thanks for the Review Lois. For the public record there's a
>>>>> conversation happening around what to do with the PermSize flags.
>>>>>
>>>>> Can I please get additional Reviews - this affects code in all teams.
>>>>>
>>>>> We need to get the JDK 10 forest buildable as JDK 10 ASAP.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>> On 27/01/2017 11:46 PM, Lois Foltan wrote:
>>>>>>
>>>>>> On 1/27/2017 12:13 AM, David Holmes wrote:
>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8173421
>>>>>>>
>>>>>>> When we try to bump the JDK version to 10 we trigger all the
>>>>>>> warnings
>>>>>>> (and an assert) surrounding the VM deprecated/obsolete/expired flag
>>>>>>> handling. In short anything that expires in 10 must now be removed;
>>>>>>> anything now obsolete in 10 must go in a different table. Related
>>>>>>> changes required to source code and tests. Gory details below.
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8173421/webrev/
>>>>>>>
>>>>>>> Testing: JPRT (in progress)
>>>>>>> Manual runs of affected regression tests
>>>>>>>
>>>>>>> This will be pushed to jdk10/jdk10 along with the actual change to
>>>>>>> bump the major version number.
>>>>>>>
>>>>>>> There are some Zero and Aarch64 code tweaks that should have been
>>>>>>> handled in JDK 9 but got overlooked somehow. Nothing significant.
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> This looks good. However, please do not remove PermSize and
>>>>>> MaxPermSize
>>>>>> in the special flag table in src/share/vm/runtime/arguments.cpp. We
>>>>>> recently added these options back in JDK 9 for ease of migration,
>>>>>> see
>>>>>> JDK-8167446. I would rather see these two options put back in the
>>>>>> table
>>>>>> and have their expiration bumped to 11 until we decide going forward
>>>>>> what is the correct course of action. Feel free to enter a new
>>>>>> JDK 10
>>>>>> specific bug to address the issue of these two options specifically.
>>>>>>
>>>>>> Thanks,
>>>>>> Lois
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>> ---
>>>>>>>
>>>>>>> Non-aliased flags:
>>>>>>>
>>>>>>> AutoGCSelectPauseMillis (def: 5000) has now expired and is removed
>>>>>>> completely from the source code.
>>>>>>>
>>>>>>> UseAutoGCSelectPolicy (def: false) has now expired and is removed
>>>>>>> completely from the source code as-if replaced by false.
>>>>>>>
>>>>>>> UseParNewGC (def: false) expired. However it is
>>>>>>> expected/required to
>>>>>>> be true whenever UseConcMarkSweepGC is true, and UseConcMarkSweepGC
>>>>>>> has not been deprecated. So we must remove all uses as-if it were
>>>>>>> true, not false.
>>>>>>>
>>>>>>> ExplicitGCInvokesConcurrentAndUnloadsClasses (def: false) has now
>>>>>>> expired and is removed completely from the source as-if replaced by
>>>>>>> false.
>>>>>>>
>>>>>>> ConvertSleepToYield (def: true) is now obsolete. It is moved to the
>>>>>>> obsolete table and is removed completely from the source code as-if
>>>>>>> replaced by true.
>>>>>>>
>>>>>>> ConvertYieldToSleep (def: false) is now obsolete. It is moved to
>>>>>>> the
>>>>>>> obsolete table and is removed completely from the source code as-if
>>>>>>> replaced by false.
>>>>>>>
>>>>>>> As a result of the above MinSleepInterval is no longer used (it
>>>>>>> should
>>>>>>> have also been deprecated in 9) and is also marked as obsolete.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Aliased options that have expired:
>>>>>>>
>>>>>>> CMSMarkStackSizeMax is an alias and has expired. It is removed from
>>>>>>> the alias and obsolete flag tables.
>>>>>>>
>>>>>>> CMSMarkStackSize is an alias and has expired. It is removed from
>>>>>>> the
>>>>>>> alias and obsolete flag tables.
>>>>>>>
>>>>>>> G1MarkStackSize is an alias and has expired. It is removed from the
>>>>>>> alias and obsolete flag tables.
>>>>>>>
>>>>>>> ParallelMarkingThreads is an alias and has expired. It is removed
>>>>>>> from
>>>>>>> the alias and obsolete flag tables.
>>>>>>>
>>>>>>> ParallelCMSThreads is an alias and has expired. It is removed from
>>>>>>> the
>>>>>>> alias and obsolete flag tables.
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> The following flags all expire in 10 and exist (except where noted)
>>>>>>> only in the special-flag table (from which they are now
>>>>>>> removed). Any
>>>>>>> other uses of the flag are removed.
>>>>>>>
>>>>>>> UseOldInlining
>>>>>>> SafepointPollOffset (defined in
>>>>>>> ./cpu/aarch64/vm/c1_globals_aarch64.hpp)
>>>>>>> UseBoundThreads (comments in os_solaris.cpp)
>>>>>>> DefaultThreadPriority
>>>>>>> NoYieldsInMicrolock
>>>>>>> BackEdgeThreshold (defined in c1/2_globals_aarch64.hpp)
>>>>>>> UseNewReflection
>>>>>>> ReflectionWrapResolutionErrors
>>>>>>> VerifyReflectionBytecodes
>>>>>>> AutoShutdownNMT
>>>>>>> NmethodSweepFraction
>>>>>>> NmethodSweepCheckInterval
>>>>>>> CodeCacheMinimumFreeSpace
>>>>>>> UseFastAccessorMethods (ZERO) (still used in
>>>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>>>> UseFastEmptyMethods (ZERO) (still used in
>>>>>>> ccpInterpreterGenerator_zero.cpp, jvmtiManageCapabilities.cpp)
>>>>>>> UseCompilerSafepoints
>>>>>>> AdaptiveSizePausePolicy
>>>>>>> ParallelGCRetainPLAB
>>>>>>> ThreadSafetyMargin
>>>>>>> LazyBootClassLoader
>>>>>>> StarvationMonitorInterval
>>>>>>> PreInflateSpin
>>>>>>> JNIDetachReleasesMonitors
>>>>>>> UseAltSigs
>>>>>>> SegmentedHeapDumpThreshold
>>>>>>> PrintOopAddress (comment in method.cpp)
>>>>>>> PermSize
>>>>>>> MaxPermSize
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Tests modified:
>>>>>>>
>>>>>>> runtime/CommandLine/
>>>>>>> ObsoleteFlagErrorMessage.java
>>>>>>> VMDeprecatedOptions.java
>>>>>>> VMAliasOptions.java
>>>>>>>
>>>>>>> gc/arguments/TestSelectDefaultGC.java
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> Tests removed (TEST.groups updated as needed):
>>>>>>>
>>>>>>> gc/startup_warnings/
>>>>>>> TestUseAutoGCSelectPolicy.java
>>>>>>> TestParNewSerialOld.java
>>>>>>> TestParNewCMS.java
>>>>>>> TestDefNewCMS.java
>>>>>>> gc/arguments/TestExplicitGCInvokesConcurrentAndUnloadsClasses.java
>>>>>>>
>>>>>>> runtime/CommandLine/PermGenFlagsTest.java
>>>>>>> runtime/NMT/AutoshutdownNMT.java
>>>>>>
>>>>
>
From ioi.lam at oracle.com Tue Jan 31 22:46:10 2017
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 31 Jan 2017 14:46:10 -0800
Subject: Easy hashtable for HotSpot
In-Reply-To: <efdee58e-668f-4028-d38b-c7470f3a6164@oracle.com>
References: <5890ED19.7070600@oracle.com>
<efdee58e-668f-4028-d38b-c7470f3a6164@oracle.com>
Message-ID: <589113B2.7030701@oracle.com>
Oh, I didn't know about ResourceHashtable. It looks much better than the
old Hashtable. Perhaps we should just convert all the old Hashtable code
to ResourceHashtable?
On 1/31/17 1:37 PM, Coleen Phillimore wrote:
>
> There is also a ResourceHashTable, did you see that? We don't need
> an *additional* hashtable, we just need a good one!
> Coleen
>
> On 1/31/17 3:01 PM, Ioi Lam wrote:
>> I've always been frustrated by the HotSpot hashtable code. It looks
>> like every time you need to create a new table, you have to write a
>> whole bunch of boilerplate code like get() and add(). This is
>> especially bad if you just need a very simple mapping.
>>
>> So I've created an "Easy" hashtable, to reduce as much boilerplate
>> code as possible:
>>
>>
>> template <class T, class Entry, MEMFLAGS F> class EasyHashtable
>> : public Hashtable<T, F>
>> {
>> static unsigned int compute_hash(T key) {
>> return Entry::compute_hash(key);
>> }
>> int hash_to_index(unsigned int hash) {
>> return Hashtable<T, F>::hash_to_index(hash);
>> }
>> public:
>> EasyHashtable(int table_size)
>> : Hashtable<T, F>(table_size, sizeof(Entry)) {}
>>
>> // For iterating all the entries in the table
>> Entry* bucket(int index) {
>> return (Entry*)Hashtable<T, F>::bucket(index);
>> }
>>
>> Entry* get(T literal) {
>> unsigned int hash = compute_hash(literal);
>> int index = hash_to_index(hash);
>> for (Entry* e = bucket(index); e != NULL; e = (Entry*)e->next()) {
>> if (e->literal() == literal) {
>> return e;
>> }
>> }
>> return NULL;
>> }
>>
>> Entry* add(T literal) {
>> unsigned int hash = compute_hash(literal);
>> int index = hash_to_index(hash);
>> Entry* e = (Entry*)Hashtable<T, F>::new_entry(hash, literal);
>> Hashtable<T, F>::add_entry(index, e);
>> return e;
>> }
>> };
>>
>>
>> Here's an example (map Symbol* -> Klass*). You just need to provide
>> your own hash function.
>>
>>
>> class SymToKlassEntry : public HashtableEntry<Symbol*, mtSymbol> {
>> Klass* _klass;
>> public:
>> static unsigned int compute_hash(Symbol* sym) {
>> return (unsigned int) sym->identity_hash();
>> }
>> void init(Klass* k) {
>> _klass = k;
>> }
>> Klass* klass() {
>> return _klass;
>> }
>> };
>>
>> void test() {
>> typedef EasyHashtable<Symbol*, SymToKlassEntry, mtSymbol> MyTable;
>> MyTable* table = new MyTable(1234);
>> Symbol* sym = SymbolTable::new_permanent_symbol("some symbol",
>> CHECK);
>> table->add(sym)->init((Klass*)0xbaadf00d);
>> Klass* klass = table->get(sym)->klass();
>>
>> // Iterate all symbols
>> for (int i=0; i<table->table_size(); i++) {
>> for (SymToKlassEntry* entry = table->bucket(i);
>> entry;
>> entry = (SymToKlassEntry*)entry->next()) {
>> tty->print_cr("sym: %p => klass: %p", entry->literal(),
>> entry->klass());
>> }
>> }
>> }
>> }
>>
>>
>>
>>
>> Another common case would be to map an address to arbitrary data
>> type. (I needed this for fixing JDK-8072061)
>>
>>
>> template <MEMFLAGS F> class AddressHashtableEntry
>> : public HashtableEntry<address, F> {
>> public:
>> static unsigned int compute_hash(address obj) {
>> return (unsigned int)(uintptr_t(obj) >> BitsPerWord);
>> }
>> };
>>
>> template <class Entry, MEMFLAGS F> class AddressHashtable
>> : public EasyHashtable<address, Entry, F> {
>> public:
>> AddressHashtable(int table_size)
>> : EasyHashtable<address, Entry, F>(table_size) {}
>>
>> Entry* get(address obj) {
>> assert(obj != NULL, "Caller should not pass in NULL");
>> return (Entry*)EasyHashtable<address, Entry, mtInternal>::get(obj);
>> }
>> Entry* add(address obj) {
>> assert(obj != NULL, "Caller should not pass in NULL");
>> return (Entry*)EasyHashtable<address, Entry, mtInternal>::add(obj);
>> }
>> };
>>
>>
>> Examples:
>>
>>
>> class AddrToNumEntry : public AddressHashtableEntry<mtInternal> {
>> int _val;
>> public:
>> void init(int v) {
>> _val = v;
>> }
>> int val() {
>> return _val;
>> }
>> };
>>
>> void test() {
>> // A table of known addresses
>> {
>> typedef AddressHashtableEntry<mtInternal> MyEntry;
>> typedef AddressHashtable<MyEntry, mtInternal> MyTable;
>> MyTable* table = new MyTable(1234);
>> table->add((address)0xdeadbeef);
>> tty->print_cr("exists? %d", (table->get((address)0xbaadf00d) !=
>> NULL));
>> tty->print_cr("exists? %d", (table->get((address)0xdeadbeef) !=
>> NULL));
>> }
>>
>> // Map addresses to numbers
>> {
>> typedef AddressHashtable<AddrToNumEntry, mtInternal> MyTable;
>> MyTable* table = new MyTable(1234);
>> table->add((address)0xdeadbeef)->init(1);
>> table->add((address)0xbaadf00d)->init(2);
>> tty->print_cr("%d", table->get((address)0xdeadbeef)->val());
>> }
>> }
>>
>>
>> Any thoughts about this coding style?
>>
>> Thanks
>> - Ioi
>>
>>
>