On Wed, 19 Jan 2022 06:47:12 GMT, Thomas Stuefe wrote:
>> Xin Liu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Intercept SIGQUIT in the early stage of HotSpot.
>
> src/hotspot/os/posix/signals_posix.cpp line 1291:
>
>> 1289: // tha
On Wed, 19 Jan 2022 07:59:28 GMT, Xin Liu wrote:
> if we install JVM_HANDLE_XXX_SIGNAL conditionally, it will leave java
> processes with -Xrs unprotected.
That's the idea. ReduceSignalUsage (Xrs) means that the hotspot should leave
this signal and some others alone:
1. On Solaris and Linux,
On Wed, 19 Jan 2022 07:15:24 GMT, David Holmes wrote:
>> This is in the signal handler. Is it safe to print message or do something
>> complex?
>
> I would not print anything here, first because it is in the signal handler
> and secondly I don't think it is needed. No real thread dump usages ar
On Wed, 19 Jan 2022 07:18:03 GMT, Ioi Lam wrote:
> > > > It seems it would be useful to support the verbose output with just a
> > > > single class that is specified, although that would suggest that the
> > > > dcmd name should then be something other than `VM.classes`.
> > >
> > >
> > > Thi
> There is a handshake protocol between attach and HotSpot. Linux
> VirtualMachineImpl sends SIGQUIT(3) if the AttachListener has not been
> initialized. It expects "Signal Dispatcher" to handle SIGBREAK(same as
> SIGQUIT) and create AttachListener. However, it is possible that attach
> starts
On Wed, 19 Jan 2022 08:36:38 GMT, Thomas Stuefe wrote:
>> I would not print anything here, first because it is in the signal handler
>> and secondly I don't think it is needed. No real thread dump usages are
>> going to hit a VM that hasn't initialized yet IMO.
>
>> This is in the signal handle
On Wed, 19 Jan 2022 09:10:56 GMT, Xin Liu wrote:
>> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The
>> default signal preposition on Linux is to quit the process and generate
>> coredump.
>>
>> There are 2 applications for this signal.
>> 1. There's a handshake protocol b
On Wed, 19 Jan 2022 09:20:07 GMT, Xin Liu wrote:
>>> This is in the signal handler. Is it safe to print message or do something
>>> complex?
>>
>> raw write to stdout should be fine I think.
>>
>>>I would not print anything here, first because it is in the signal handler
>>>and secondly I don
On Wed, 19 Jan 2022 09:35:01 GMT, Thomas Stuefe wrote:
>> because JVM_HANDLE_XXX_SIGNAL is installed in os::init_2(), it's safe to use
>> log. I added a log entry with the tag os+init. -Xlog:os+init=info will
>> print out a message "ignore BREAK_SIGNAL in the initialization phase." I
>> also
On Wed, 19 Jan 2022 09:10:56 GMT, Xin Liu wrote:
>> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The
>> default signal preposition on Linux is to quit the process and generate
>> coredump.
>>
>> There are 2 applications for this signal.
>> 1. There's a handshake protocol b
On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote:
>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>>
>> Also we can undo the property-setting Launcher.gmk change from: 8279007:
>> jstatd fails to start because SecurityManager is disabled
On Wed, 19 Jan 2022 12:39:31 GMT, Kevin Walls wrote:
> So I like the change but would like to be clearer where the problem exists,
> where (what platforms?) can we see no signals ignored or caught at startup,
> and trigger the problem of crashing the VM with SIGQUIT.
I reproduced it with my ar
> The JDWP spec mentions nothing about `DisableCollection` and
> `EnableCollection` tracking the depth or nesting of the commands. This means
> that `EnableCollection` should enable collection no matter how many
> `DisableCollection` commands were done before it. This is how the debug agent
> u
On Wed, 19 Jan 2022 08:39:34 GMT, Xin Liu wrote:
> > How about this:
> > ```
> > jcmd VM.classes -verbose classname classname ...
> > ```
> >
> > -verbose is optional
> > more than one classnames can be specified.
> > if no classnames are specified, all classes are printed
>
> If the class na
> For any SA test that attaches to an OSX process (this would be all SA tests
> except for those that test core file support), there is a check to make sure
> that the target jvm process is not a signed binary. If it is,
> SkippedException is thrown, and the test passes without doing anything. T
On Wed, 19 Jan 2022 06:50:19 GMT, David Holmes wrote:
> Hi Chris,
>
> Seems fine. My only query/concern here is how reliable/stable this codesign
> verbose output is?
>
> Thanks, David
Hard to say, but this seems like the best solution at the moment. We can always
adapt/adjust if needed.
>
On Mon, 10 Jan 2022 11:17:12 GMT, Kevin Walls wrote:
>> Remove the use of Security Manager from jstatd.
>> Add use of an ObjectInputFilter to restrict RMI.
>>
>> Also we can undo the property-setting Launcher.gmk change from: 8279007:
>> jstatd fails to start because SecurityManager is disabled
On Wed, 19 Jan 2022 16:40:08 GMT, Chris Plummer wrote:
>> The JDWP spec mentions nothing about `DisableCollection` and
>> `EnableCollection` tracking the depth or nesting of the commands. This means
>> that `EnableCollection` should enable collection no matter how many
>> `DisableCollection` c
On Wed, 19 Jan 2022 18:22:13 GMT, Chris Plummer wrote:
>> For any SA test that attaches to an OSX process (this would be all SA tests
>> except for those that test core file support), there is a check to make sure
>> that the target jvm process is not a signed binary. If it is,
>> SkippedExcep
Forwardport JDK 18 -> JDK 19
-
Commit messages:
- Merge
- 8280233: Temporarily disable Unix domain sockets in Windows PipeImpl
- 8278834: Error "Cannot read field "sym" because "this.lvar[od]" is null"
when compiling
- 8272058: 25 Null pointer dereference defect groups in 4 files
On Thu, 20 Jan 2022 00:28:55 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 18 -> JDK 19
This pull request has now been integrated.
Changeset: 4616c13c
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/4616c13c2f1ced8a8bdeed81f0469523932e91b5
Stats: 1732
On Wed, 19 Jan 2022 22:23:03 GMT, David Holmes wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Get rid of isStrong flag and instead just compute it based on the value of
>> isPinAll and isCommonPin. Add comments
On Thu, 13 Jan 2022 08:25:22 GMT, Andrey Turbanov wrote:
> Method `Class.isAssignableFrom` is often used in form of:
>
> if (clazz.isAssignableFrom(obj.getClass())) {
> Such condition could be simplified to more shorter and performarnt code
>
> if (clazz.isInstance(obj)) {
>
> Repl
> The JDWP spec mentions nothing about `DisableCollection` and
> `EnableCollection` tracking the depth or nesting of the commands. This means
> that `EnableCollection` should enable collection no matter how many
> `DisableCollection` commands were done before it. This is how the debug agent
> u
On Thu, 20 Jan 2022 04:22:28 GMT, Chris Plummer wrote:
>> The JDWP spec mentions nothing about `DisableCollection` and
>> `EnableCollection` tracking the depth or nesting of the commands. This means
>> that `EnableCollection` should enable collection no matter how many
>> `DisableCollection` c
> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The default
> signal preposition on Linux is to quit the process and generate coredump.
>
> There are 2 applications for this signal.
> 1. There's a handshake protocol between sun.tools.attach and HotSpot.
> VirtualMachineImpl
On Thu, 20 Jan 2022 05:03:13 GMT, David Holmes wrote:
> Fixes for NULL case look good.
>
> Thanks, David
Thanks for the review and noticing these issues.
-
PR: https://git.openjdk.java.net/jdk/pull/7134
On Wed, 19 Jan 2022 12:39:31 GMT, Kevin Walls wrote:
>> Xin Liu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Only install JVM_HANDLE_XXX_SIGNAL when ReduceSignalUsage is
>> false(default value).
>>
>> This patch also adds a log
> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The default
> signal preposition on Linux is to quit the process and generate coredump.
>
> There are 2 applications for this signal.
> 1. There's a handshake protocol between sun.tools.attach and HotSpot.
> VirtualMachineImpl
On Wed, 19 Jan 2022 12:06:49 GMT, David Holmes wrote:
>> Sorry for being difficult, but I would not do UL logging here. UL is
>> heavyweight, and a shifting target too, because folks like to extend it with
>> new capabilities. God knows what log_info really does (initialization,
>> network tra
On Thu, 20 Jan 2022 06:05:22 GMT, Xin Liu wrote:
>> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The
>> default signal preposition on Linux is to quit the process and generate
>> coredump.
>>
>> There are 2 applications for this signal.
>> 1. There's a handshake protocol b
On Thu, 20 Jan 2022 06:05:22 GMT, Xin Liu wrote:
>> In early stage of initialization, HotSpot doesn't handle SIGQUIT. The
>> default signal preposition on Linux is to quit the process and generate
>> coredump.
>>
>> There are 2 applications for this signal.
>> 1. There's a handshake protocol b
> Add VM.classes to print details of all classes, output looks like:
>
> 1. jcmd VM.classes
>
> KlassAddr Size State Flags LoaderName ClassName
> 0x000800c0b400 62 inited W bootstrap
> java.lang.invoke.LambdaForm$MH/0x000800c0b400
> 0x000800c0b000 62 inited W bootstrap
> java.lang.i
On Wed, 19 Jan 2022 02:37:10 GMT, Yi Yang wrote:
>> Add VM.classes to print details of all classes, output looks like:
>>
>> 1. jcmd VM.classes
>>
>> KlassAddr Size State Flags LoaderName ClassName
>> 0x000800c0b400 62 inited W bootstrap
>> java.lang.invoke.LambdaForm$MH/0x000800c0b400
34 matches
Mail list logo
