On Sat, 22 Apr 2023 00:09:27 GMT, Serguei Spitsyn wrote:
>> For the JDI tests I added, I execute them in both modes, with the
>> appropriate adjustments to account for the errors we except for virtual
>> threads. We should be testing to make sure that StopThread works with
>> platform threads
On Tue, 25 Apr 2023 03:49:09 GMT, Chris Plummer wrote:
>>> The scenario that I'm wondering about is where a virtual thread is resumed
>>> at around the same time that JVMTI StopThread is called.
>>
>> This kind of scenario is not typical.
>> The debugger should keep virtual thread suspended when
> This enhancement adds support of virtual threads to the JVMTI `StopThread`
> function.
> In preview releases before this enhancement the StopThread returned the
> JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads.
>
> The `StopThread` supports sending an asynchronous exception t
On Tue, 25 Apr 2023 03:06:09 GMT, Serguei Spitsyn wrote:
>> ProcessTools.startProcess() creates process and read it's output error
>> streams. So the any other using of corresponding Process.getInputStream()
>> and Process.getErrorStream() doesn't get process streams.
>>
>> This fix preserve p
On Tue, 25 Apr 2023 02:15:54 GMT, Serguei Spitsyn wrote:
>> Seems we should have a stress test for that.
>
>> The scenario that I'm wondering about is where a virtual thread is resumed
>> at around the same time that JVMTI StopThread is called.
>
> This kind of scenario is not typical.
> The deb
On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process
On Mon, 24 Apr 2023 20:26:31 GMT, Chris Plummer wrote:
>> The scenario that I'm wondering about is where a virtual thread is resumed
>> at around the same time that JVMTI StopThread is called. Not easy to test.
>
> Seems we should have a stress test for that.
> The scenario that I'm wondering a
On Mon, 24 Apr 2023 20:57:31 GMT, Chris Plummer wrote:
>> ProcessTools.startProcess() creates process and read it's output error
>> streams. So the any other using of corresponding Process.getInputStream()
>> and Process.getErrorStream() doesn't get process streams.
>>
>> This fix preserve pro
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c.
> - throwByName() in
> src/jdk.crypt
On Mon, 24 Apr 2023 22:41:53 GMT, Mark Powers wrote:
> Update copyrights to 2023.
Done, thanks.
> src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201:
>
>> 199: cb = malloc(sizeof(struct gss_channel_bindings_struct));
>> 200: if (cb == NULL) {
>> 201: gssThrowOutOfMemory
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj
I'll take a look.
From: security-dev on behalf of Jiangli Zhou
Sent: Monday, April 24, 2023 10:27 AM
To: jmx-...@openjdk.org ; security-...@openjdk.org
; serviceability-dev@openjdk.org
Subject: Re: RFR: 8306033: Resolve multiple definition of 'throwIOException
On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote:
> ProcessTools.startProcess() creates process and read it's output error
> streams. So the any other using of corresponding Process.getInputStream() and
> Process.getErrorStream() doesn't get process streams.
>
> This fix preserve process
On Sat, 22 Apr 2023 08:01:20 GMT, Alan Bateman wrote:
>> Thank you for the catch. Will check it. I have to extend the test to cover
>> the BoundVirtualThread case enabled with the flag `-XX:-VMContinuations`.
>
> The scenario that I'm wondering about is where a virtual thread is resumed at
> ar
On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote:
>> Please review this change to the string deduplication thread to make it a
>> kind
>> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
>> this change:
>>
>> (1) New class StringDedupThread (derived from JavaThrea
On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote:
>> This change adds a fast-locking scheme as an alternative to the current
>> stack-locking implementation. It retains the advantages of stack-locking
>> (namely fast locking in uncontended code-paths), while avoiding the overload
>> of the
On Mon, 17 Apr 2023 20:00:58 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 156 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2
>> - A few more LM_ pr
On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote:
> - Make functions 'static' when feasible:
> - throwByName() in
> src/java.security.jgss/share/native/libj2gss/NativeUtil.c.
> - throwByName(), throwIOException() and throwNullPointerException() in
> src/java.smartcardio/unix/native/libj
On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to increase timeouts for tests that timeout under heavy stress:
> [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for
> JLI GetObjectSizeIntrinsicsTest.java subtest again
> [JDK-8305502](https
On Mon, 24 Apr 2023 05:24:20 GMT, Tobias Hartmann wrote:
>> Trivial fixes to increase timeouts for tests that timeout under heavy stress:
>> [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout
>> for JLI GetObjectSizeIntrinsicsTest.java subtest again
>> [JDK-8305502](https:
On Mon, 24 Apr 2023 09:39:07 GMT, Aleksey Shipilev wrote:
> I like this simplification a lot, thanks! I am running some Shenandoah
> string-dedup tests now.
Ran `gc/shenandoah/TestStringDedup*` on x86_64 and AArch64 for 100 times
without a problem. These tests usually fail when there are bugs
On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X
On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote:
>> Please review this change to the string deduplication thread to make it a
>> kind
>> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
>> this change:
>>
>> (1) New class StringDedupThread (derived from JavaThrea
On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote:
> Please review this change to the string deduplication thread to make it a kind
> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
> this change:
>
> (1) New class StringDedupThread (derived from JavaThread), separ
> Please review this change to the string deduplication thread to make it a kind
> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
> this change:
>
> (1) New class StringDedupThread (derived from JavaThread), separate from
> StringDedup::Processor (which is now just a
On Mon, 24 Apr 2023 09:00:53 GMT, Stefan Karlsson wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix include order
>
> src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 29:
>
>> 27:
>> 28: #in
On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote:
> Please review this change to the string deduplication thread to make it a kind
> of JavaThread rather than a ConcurrentGCThread. There are several pieces to
> this change:
>
> (1) New class StringDedupThread (derived from JavaThread), separ
Please review this change to the string deduplication thread to make it a kind
of JavaThread rather than a ConcurrentGCThread. There are several pieces to
this change:
(1) New class StringDedupThread (derived from JavaThread), separate from
StringDedup::Processor (which is now just a CHeapObj ins
28 matches
Mail list logo
