> This change have been already reviewed by Mandy, Sundar, Alan and David.
> Please, see the jdk 15 review thread:
>
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>
> Now, the PR approval is needed.
> The push was postponed because the CSR was not approved at
Hi David,
I'm not sure you mean exactly by DLL unloading mechanism is not hooked.
I want to say we do not hook `FreeLibrary()` on Windows and `dlclose()` on
Linux.
Can we describe ""this function may be called - " at here?
Cheers,
Yasumasa
On 2020/12/16 15:48, David Holmes wrote:
On 16/1
> This change have been already reviewed by Mandy, Sundar, Alan and David.
> Please, see the jdk 15 review thread:
>
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-June/031998.html
>
> Now, the PR approval is needed.
> The push was postponed because the CSR was not approved at
On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote:
Hi David,
"This function will be called by the VM when the library is about to
be unloaded. The library will be unloaded (unless it is statically
linked into the executable) and this function will be called if some
platform specific mechanism cau
Hi David,
"This function will be called by the VM when the library is about to be unloaded.
The library will be unloaded (unless it is statically linked into the executable) and
this function will be called if some platform specific mechanism causes the unload (an
unload mechanism is not spec
Hi Mandy,
On 16/12/2020 12:54 pm, Mandy Chung wrote:
On 12/15/20 5:50 PM, David Holmes wrote:
On 16/12/2020 11:35 am, Serguei Spitsyn wrote:
On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes
wrote:
The agent class doesn't have to be public it just has to be accessible.
The premain method sho
On 12/15/20 5:50 PM, David Holmes wrote:
On 16/12/2020 11:35 am, Serguei Spitsyn wrote:
On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes
wrote:
The agent class doesn't have to be public it just has to be accessible.
The premain method should be queried for public modifier rather than
just re
On Wed, 16 Dec 2020 01:32:53 GMT, Serguei Spitsyn wrote:
>> The agent class doesn't have to be public it just has to be accessible.
>>
>> The premain method should be queried for public modifier rather than just
>> relying on a failed invocation request.
>
> David, thank you for catching this.
Hi Yasumasa,
Sorry for the delay getting back to this.
On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote:
Hi David,
On 2020/12/01 14:59, David Holmes wrote:
Looking at the original webrev from September:
https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExpo
On 16/12/2020 11:35 am, Serguei Spitsyn wrote:
On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes wrote:
The agent class doesn't have to be public it just has to be accessible.
The premain method should be queried for public modifier rather than just
relying on a failed invocation request.
Davi
On Wed, 16 Dec 2020 00:50:04 GMT, David Holmes wrote:
>> Mandy, thank you for the suggestion.
>> I'll retarget the bug and CSR to jdk 17 as nobody is objecting.
>>
>> Also, wanted to make it clear about Exception messages that are provided for
>> two different cases.
>>
>> The test java/lang/i
On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo
wrote:
> Hi,
>
> Please review the following small fix for test
> RemovingUnixDomainSocketTest.java. As explained in the bug comments, the
> issue is due to having two different StreamPumper objects consuming from the
> same stderr, on
On Wed, 16 Dec 2020 00:15:36 GMT, Serguei Spitsyn wrote:
>> Alan, David and Many, thank you for the comments!
>> I'll prepare an update according to the recent requests from you.
>> One question is if I need to clone this PR to the JDK 16 fork:
>> https://github.com/openjdk/jdk16
>> It depends
On Mon, 14 Dec 2020 22:45:26 GMT, Serguei Spitsyn wrote:
>> Changes requested by dholmes (Reviewer).
>
> Alan, David and Many, thank you for the comments!
> I'll prepare an update according to the recent requests from you.
> One question is if I need to clone this PR to the JDK 16 fork:
> https
On Tue, 15 Dec 2020 23:41:31 GMT, Daniel D. Daugherty
wrote:
>> See bug for details. Tested:
>>
>> $ java -XX:+StressLdcRewrite -version
>> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
>> -XX:+UnlockDiagnosticVMOptions.
>> Error: The unlock option must precede 'St
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
On Tue, 15 Dec 2020 23:14:14 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or rejec
On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks wrote:
>> It's an adverb, since it's the act of 'defining' that is being done too
>> restrictively or broadly. If you want to have an adjective you would need to
>> rephrase it so it applies to the noun, like 'defining a too restrictive
>> accept-
On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
On Tue, 15 Dec 2020 22:21:12 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as follows:
> 1. grandfathered -> legacy
> 2. blacklist -> filter or rejec
On Tue, 15 Dec 2020 09:17:03 GMT, Magnus Ihse Bursie wrote:
>> Your call, I'm not a native English speaker :-) It felt to me it's
>> 'restrictive' than 'restrictively', an adj placed after the noun, e.g. a
>> restrictive allow-list.
>
> It's an adverb, since it's the act of 'defining' that is
On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen wrote:
>> test/jdk/java/lang/ClassLoader/Assert.java line 65:
>>
>>> 63:
>>> 64: int switchSource = 0;
>>> 65: if (args.length == 0) { // This is the coordinator version
>>
>> Perhaps s/coordinator/controller/?
>
> Let's change i
On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates, per code review
>
> test/jdk/java/lang/ClassLoader/Assert.java line 65:
>
>> 63:
>> 64: int s
On Tue, 15 Dec 2020 01:46:08 GMT, Brent Christian wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
On Fri, 11 Dec 2020 17:25:33 GMT, Patricio Chilano Mateo
wrote:
> Hi,
>
> Please review the following small fix for test
> RemovingUnixDomainSocketTest.java. As explained in the bug comments, the
> issue is due to having two different StreamPumper objects consuming from the
> same stderr, on
On Tue, 15 Dec 2020 17:54:05 GMT, Thomas Stuefe wrote:
> I cannot believe anyone uses this option in earnest in production. Still, out
> of sheer fascination I googled but did not find any serious usage.
I discussed this with @dcubed-ojdk who added this for a customer situation and
this was his
On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates, per code review
>
> test/jdk/java/nio/channels/SocketChannel/CloseRegisteredChannel.java line 45:
>
>> 43:
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
On Tue, 15 Dec 2020 17:26:25 GMT, Coleen Phillimore wrote:
> See bug for details. Tested:
>
> $ java -XX:+StressLdcRewrite -version
> Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
> -XX:+UnlockDiagnosticVMOptions.
> Error: The unlock option must precede 'StressLdcRe
See bug for details. Tested:
$ java -XX:+StressLdcRewrite -version
Error: VM option 'StressLdcRewrite' is diagnostic and must be enabled via
-XX:+UnlockDiagnosticVMOptions.
Error: The unlock option must precede 'StressLdcRewrite'.
Error: Could not create the Java Virtual Machine.
Error: A fatal
On Mon, 14 Dec 2020 23:58:43 GMT, Alex Menkov wrote:
>> Hi,
>>
>> Please review the following small fix for test
>> RemovingUnixDomainSocketTest.java. As explained in the bug comments, the
>> issue is due to having two different StreamPumper objects consuming from the
>> same stderr, one crea
On Mon, 23 Nov 2020 19:58:20 GMT, Severin Gehwolf wrote:
>>> With respect to JDK-8255908, the changes look good to me.
>>
>> Thanks!
>
> @bobvandette Please review when you've got some cycles to spare. Much
> appreciated!
Ping? Anyone?
-
PR: https://git.openjdk.java.net/jdk/pull/
On Tue, 15 Dec 2020 01:41:07 GMT, Joe Wang wrote:
>> I agree that there is room for improvement here. How about:
>> "...an allow-list too restrictively, or a reject-list too broadly, may..."
>> ?
>
> Your call, I'm not a native English speaker :-) It felt to me it's
> 'restrictive' than 'restr
On Fri, 4 Dec 2020 15:30:15 GMT, Richard Reingruber wrote:
> This fixes a bug in the test test/jdk/com/sun/jdi/EATests.java that caused
> timeout failures when graal is enabled.
>
> The fix is to avoid suspending all threads when a breakpoint is reached and
> then resume
> just the main thread
On Fri, 11 Dec 2020 08:43:16 GMT, Richard Reingruber wrote:
>> Marked as reviewed by cjplummer (Reviewer).
>
> @plummercj, @sspitsyn, thanks again for the review.
>
> I would like to bring the fix to jdk16. According to
> https://openjdk.java.net/jeps/3 this is possible in RDP1 for test bug fix
On Fri, 11 Dec 2020 20:53:37 GMT, Chris Plummer wrote:
>> This is a clone of https://github.com/openjdk/jdk/pull/1625 which was
>> reviewed but not integrated before RDP1
>>
>> The change is a test bug fix which can be integrated during RDP1 according
>> to https://openjdk.java.net/jeps/3
>>
On Fri, 11 Dec 2020 09:03:44 GMT, Richard Reingruber wrote:
> This is a clone of https://github.com/openjdk/jdk/pull/1625 which was
> reviewed but not integrated before RDP1
>
> The change is a test bug fix which can be integrated during RDP1 according to
> https://openjdk.java.net/jeps/3
>
>
42 matches
Mail list logo
