Re: RFR: 8279134: Fix Amazon copyright in various files
On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote: > This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094 > > Currently, some of the files in the OpenJDK repo have Amazon copyright > notices which are all slightly different and do not conform to Amazons > preferred copyright notice which is simply (intentionally without copyright > year): > > "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved." > > @simonis @phohensee Lgtm. - Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6915
Re: RFR: 8271737: Only normalize the cached user.dir property once
On Thu, 7 Oct 2021 14:05:19 GMT, Evgeny Astigeevich wrote: > The change completes the fix of > [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has > added normalisation in a constructor but not removed it from the get method. Lgtm. - Marked as reviewed by phh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5850
Re: Request for Review (XXL): 7104647: Adding a diagnostic command framework
For the hotspot part:
In attachListener.cpp, you might want to delete the first return JNI_OK;
line, since the code under HAS_PENDING_EXCEPTION just falls through.
In jmm.h, minor formatting nit: be nice to indent (JNIEnv on lines 318,
319 and 325 the same as the existing declarations. Add a newline
just before it on line 322.
On 12/2/11 8:57 AM, Frederic Parain wrote:
Hi All,
[Posting to serviceability-dev, runtime-dev and core-libs-dev
because changes are pretty big and touch all these areas]
Here's a framework for issuing diagnostics commands to the JVM.
Diagnostic commands are actions executed inside the JVM mainly
for monitoring or management purpose. This work has two parts.
The first part is in the hotspot repository and contains the
framework itself with two diagnostic commands. The second
part is in the JDK repository and contains the command line
utility to invoke diagnostic commands as well as the
HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean
extensions allow a remote client to discover and invoke
diagnostic commands using a JMX connection.
This changeset only contains two diagnostic commands, more
commands will be added in the future, as a standalone effort
to improve the monitoring and management services of the
JVM, or as part of other projects.
Webrevs are here:
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/
http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/
Here's a technical description of this work:
1 - The Diagnostic Command Framework
1-1 Overview
The diagnostic command framework is fully implemented in native code
and relies on the HotSpot's internal exception mechanism.
The rational of a pure native implementation is to be able to execute
diagnostic commands even in critical situations like an OutOfMemory
error. All diagnostic commands are registered in a single list, and two
flags control the way a user can interact with them. The hidden flag
prevents a diagnostic command from appearing in the list of available
commands returned by the help command. However, it's still possible to
get the detailed help message for a hidden command with the help
command name syntax (but it requires to know the name of the hidden
command). The second flag is enabled and it controls if a command can
be invoked or not. When listed with the help commands, disabled
commands appear with a [disabled] label in their description. If the
user tries to invoke a disabled command, an error message is returned
and the command is not run. This error message can be customized on a
per command base. The framework just provides these two flags with their
semantic, it doesn't provide any policy or mechanism to set or modify
these flags. These actions will be delegated to the JVM or special
diagnostic commands.
1-2 Implementation
All diagnostic commands are implemented as subclasses of the DCmd class
defined in services/diagnosticFramework.hpp. Here's the layout of the
DCmd class and the list of methods that a new command has to define or
overwrite:
class DCmd {
DCmd(outputStream *output);
static const char *get_name();
static const char *get_description();
static const char *get_disabled_message();
static const char *get_impact();
static int get_num_arguments();
virtual void print_help(outputStream* out);
virtual void parse(CmdLine* line, char delim, TRAPS);
virtual void execute(TRAPS);
virtual void reset(TRAPS);
virtual void cleanup();
virtual GrowableArrayconst char ** get_argument_name_array();
virtual GrowableArrayDCmdArgumentInfo** get_argument_info_array();
}
A diagnostic command is always instantiated with an outputStream in
parameter. This outputStream can point either to a file, a buffer or a
socket (see the ostream.hpp file).
The get_name() method returns the string that will identify the command
(i.e. the string to put on the command line to invoke it).
The get_description() methods returns the global description of the
command.
The get_disabled_message() returns the customized message to return when
the command is disabled, without having to instantiate the command.
The get_impact() returns a description of the intrusiveness of the
diagnostic command on the Java Virtual Machine behavior. The rational
for this method is that some diagnostic commands can seriously disrupt
the behavior of the Java Virtual Machine (for instance a Thread Dump for
an application with several tens of thousands of threads, or a Head Dump
with a 40GB+ heap size) and other diagnostic commands have no serious
impact on the JVM (for instance, getting the command line arguments or
the JVM version). The recommended format for the description is impact
level: [longer description], where the impact level is selected among
this list: {low, medium, high}. The optional longer description can
provide more specific details like the fact that Thread Dump impact
depends on the heap size.
The get_num_arguments() returns the number of options/arguments
recognized by
Re: Request for Review (XXL): 7104647: Adding a diagnostic command framework
This is just the start of a review: fumble-fingers sent it well before
it's time.
Paul
On 12/7/11 4:15 PM, Paul Hohensee wrote:
For the hotspot part:
In attachListener.cpp, you might want to delete the first return
JNI_OK;
line, since the code under HAS_PENDING_EXCEPTION just falls through.
In jmm.h, minor formatting nit: be nice to indent (JNIEnv on lines 318,
319 and 325 the same as the existing declarations. Add a newline
just before it on line 322.
On 12/2/11 8:57 AM, Frederic Parain wrote:
Hi All,
[Posting to serviceability-dev, runtime-dev and core-libs-dev
because changes are pretty big and touch all these areas]
Here's a framework for issuing diagnostics commands to the JVM.
Diagnostic commands are actions executed inside the JVM mainly
for monitoring or management purpose. This work has two parts.
The first part is in the hotspot repository and contains the
framework itself with two diagnostic commands. The second
part is in the JDK repository and contains the command line
utility to invoke diagnostic commands as well as the
HotSpotDiagnosticMXBean extensions. The HotSpotDiagnosticMXBean
extensions allow a remote client to discover and invoke
diagnostic commands using a JMX connection.
This changeset only contains two diagnostic commands, more
commands will be added in the future, as a standalone effort
to improve the monitoring and management services of the
JVM, or as part of other projects.
Webrevs are here:
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.00/
http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.00/
Here's a technical description of this work:
1 - The Diagnostic Command Framework
1-1 Overview
The diagnostic command framework is fully implemented in native code
and relies on the HotSpot's internal exception mechanism.
The rational of a pure native implementation is to be able to execute
diagnostic commands even in critical situations like an OutOfMemory
error. All diagnostic commands are registered in a single list, and two
flags control the way a user can interact with them. The hidden flag
prevents a diagnostic command from appearing in the list of available
commands returned by the help command. However, it's still possible to
get the detailed help message for a hidden command with the help
command name syntax (but it requires to know the name of the hidden
command). The second flag is enabled and it controls if a command can
be invoked or not. When listed with the help commands, disabled
commands appear with a [disabled] label in their description. If the
user tries to invoke a disabled command, an error message is returned
and the command is not run. This error message can be customized on a
per command base. The framework just provides these two flags with their
semantic, it doesn't provide any policy or mechanism to set or modify
these flags. These actions will be delegated to the JVM or special
diagnostic commands.
1-2 Implementation
All diagnostic commands are implemented as subclasses of the DCmd class
defined in services/diagnosticFramework.hpp. Here's the layout of the
DCmd class and the list of methods that a new command has to define or
overwrite:
class DCmd {
DCmd(outputStream *output);
static const char *get_name();
static const char *get_description();
static const char *get_disabled_message();
static const char *get_impact();
static int get_num_arguments();
virtual void print_help(outputStream* out);
virtual void parse(CmdLine* line, char delim, TRAPS);
virtual void execute(TRAPS);
virtual void reset(TRAPS);
virtual void cleanup();
virtual GrowableArrayconst char ** get_argument_name_array();
virtual GrowableArrayDCmdArgumentInfo** get_argument_info_array();
}
A diagnostic command is always instantiated with an outputStream in
parameter. This outputStream can point either to a file, a buffer or a
socket (see the ostream.hpp file).
The get_name() method returns the string that will identify the command
(i.e. the string to put on the command line to invoke it).
The get_description() methods returns the global description of the
command.
The get_disabled_message() returns the customized message to return when
the command is disabled, without having to instantiate the command.
The get_impact() returns a description of the intrusiveness of the
diagnostic command on the Java Virtual Machine behavior. The rational
for this method is that some diagnostic commands can seriously disrupt
the behavior of the Java Virtual Machine (for instance a Thread Dump for
an application with several tens of thousands of threads, or a Head Dump
with a 40GB+ heap size) and other diagnostic commands have no serious
impact on the JVM (for instance, getting the command line arguments or
the JVM version). The recommended format for the description is impact
level: [longer description], where the impact level is selected among
this list: {low, medium, high}. The optional longer description can
provide more specific details like
hg: jdk7/tl/jdk: 4 new changesets
Changeset: c73c178159d8 Author:phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c73c178159d8 6173675: MM: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author:phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author:phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author:phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java
Re: signal chaining and self defence
A partial answer: one of the Hotspot engineers says I think the short answer is that chaining requires LD_PRELOAD to override the signal entry points. Otherwise we [Hotspot] wouldn't see the calls that change the signal handlers. If the Java command itself linked against jsig that would work too I think. I believe that's the only way to solve the problem he is seeing in an automatic fashion. Depending on how the driver library gets loaded they might be able to build their own signal handler trampolines to work around it and correct the signal handlers after it gets loaded. Regards, Paul On 5/8/10 7:31 AM, Michael Bien wrote: Hello everyone, i am one of the maintainers of JOGL and wrote JOCL (http://jogamp.org/) and we are currently facing some signal handling issues caused by the nvidia and amd drivers. (I got the hint to post to this list since there is no better alias for this kind of topics) e.g. the nvidia OpenCL driver uses at least the following handlers: Warning: SIGSEGV handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGILL handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGFPE handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGBUS handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGXFSZ handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 (-Xcheck:jni) which basically makes the jvm unusable on Linux and leads to segmentation faults (in the driver, I suppose the driver catches jvm signals). LD_PRELOAD (http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html#gbzbl) works perfectly but it is not allowed for webstart + applets... do you have any advice how we could workaround this issue? The perfect solution would be a -XX:enableSignalChaining flag which we could set via jnlp. Since the webstart JVM is out of process anyway (since u10 or so) this would probably work. Why isn't signal chaining enabled by default on linux and solaris? It looks like a good self-defence mechanism for me :) best regards, Michael Bien --- http://michael-bien.com
Re: signal chaining and self defence
More info from Hotspot engineers. Does webstart allow running your own native code in an applet? (Does plugin while So I am guessing that they have java interfaces using the jvm/JIT - then gluegen -- how does gluegen work here? Is it precompiled or does it do a translation at run time? - which talks to OpenCL C binaries - there appear to be a set running on the host or main CPU, including interfacing to the underlying device drivers, such as the amd and nvidia drivers mentioned - which then can also start OpenCL C binaries that run on auxiliary processors like GPUs So to answer Michael's question from a VM perspective: It appears that the amd and nvidia native drivers that I would guess they link to in their host code register for the system signals listed below, but don't support signal chaining, i.e. they are overwriting the jvm's signal handlers. So - the technical solution for that, assuming we can't change the amd and nvidia drivers, is to interpose our libjsig.so before their libraries are loaded. This lets our vm chain their signal handlers, so that the VM only handles signals that apply to the vm and then calls their signal handlers. I am guessing they can't link libjsig with their application or he would have done so - but it is worth first asking why he can't. If it is the case that he can not, then he needs to setenv LD_PRELOAD libjvm.so-directory/libjsig.so before starting up java. Is there a way to do that with WebStart? Is there a way to specify to do that? No - there is no ability to set any env variables before launching java. If jnlp file itself is signed and trusted, you could set system propertys before launching java, but not environmental variables. - Paul A partial answer: one of the Hotspot engineers says I think the short answer is that chaining requires LD_PRELOAD to override the signal entry points. Otherwise we [Hotspot] wouldn't see the calls that change the signal handlers. If the Java command itself linked against jsig that would work too I think. I believe that's the only way to solve the problem he is seeing in an automatic fashion. Depending on how the driver library gets loaded they might be able to build their own signal handler trampolines to work around it and correct the signal handlers after it gets loaded. Regards, Paul On 5/8/10 7:31 AM, Michael Bien wrote: Hello everyone, i am one of the maintainers of JOGL and wrote JOCL (http://jogamp.org/) and we are currently facing some signal handling issues caused by the nvidia and amd drivers. (I got the hint to post to this list since there is no better alias for this kind of topics) e.g. the nvidia OpenCL driver uses at least the following handlers: Warning: SIGSEGV handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGILL handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGFPE handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGBUS handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 Warning: SIGXFSZ handler expected:libjvm.so+0x5d8cf0 found:libnvidia-compiler.so+0x1865e0 (-Xcheck:jni) which basically makes the jvm unusable on Linux and leads to segmentation faults (in the driver, I suppose the driver catches jvm signals). LD_PRELOAD (http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/signals.html#gbzbl) works perfectly but it is not allowed for webstart + applets... do you have any advice how we could workaround this issue? The perfect solution would be a -XX:enableSignalChaining flag which we could set via jnlp. Since the webstart JVM is out of process anyway (since u10 or so) this would probably work. Why isn't signal chaining enabled by default on linux and solaris? It looks like a good self-defence mechanism for me :) best regards, Michael Bien --- http://michael-bien.com
Re: Kinda ?
in a way plus somewhat, as in it's kinda bad == in a way, it's somewhat bad. On 3/22/10 7:02 PM, Ulf Zibis wrote: Can somebody betray the sense of Kinda to me? -Ulf
