On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev
wrote:
> Dear colleagues,
>
> Please review the patch that replaces the lambdas with anonymous classes
> which solves the startup time regression as shown below.
>
> I attached the Bytestacks flamegraphs for both original (regression) and
On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov
wrote:
> Please review this PR which fixes the deadlock in ClassLoader between the two
> lock objects - a lock object associated with the class being loaded, and the
> ClassLoader.loadedLibraryNames hash map, locked during the nativ
On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov
wrote:
> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
> against JDK17.
>
> This fixes the deadlock in ClassLoader between the two lock objects - a lock
> object associated with the cla
On Fri, 18 Jun 2021 09:50:49 GMT, Aleksei Voitylov
wrote:
> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
> against JDK17.
>
> This fixes the deadlock in ClassLoader between the two lock objects - a lock
> object associated with the cla
On Mon, 21 Jun 2021 16:49:30 GMT, Mandy Chung wrote:
>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
>> against JDK17.
>>
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock
>> object associated with the class being loaded, and the
>>
On Mon, 21 Jun 2021 13:26:14 GMT, Alan Bateman wrote:
>> Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976
>> against JDK17.
>>
>> This fixes the deadlock in ClassLoader between the two lock objects - a lock
>> object associated with the class being loaded, and the
>>
Resubmitting the following PR https://github.com/openjdk/jdk/pull/3976 against
JDK17.
This fixes the deadlock in ClassLoader between the two lock objects - a lock
object associated with the class being loaded, and the
ClassLoader.loadedLibraryNames hash map, locked during the native library
On Wed, 16 Jun 2021 07:51:32 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
On Wed, 16 Jun 2021 15:59:44 GMT, Mandy Chung wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comments
>
> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLo
On Mon, 14 Jun 2021 18:30:23 GMT, Mandy Chung wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comments
>
> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/LoadL
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one a
On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
On Mon, 31 May 2021 23:57:09 GMT, Mandy Chung wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comments
>
> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLo
On Fri, 11 Jun 2021 10:03:44 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one a
On Mon, 31 May 2021 20:56:14 GMT, Mandy Chung wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comments
>
> src/java.base/share/classes/jdk/internal/loader
On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
On Wed, 26 May 2021 07:30:10 GMT, Peter Levart wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibr
On Wed, 26 May 2021 02:36:34 GMT, David Holmes wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibr
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one a
On 25/05/2021 04:44, David Holmes wrote:
> On 25/05/2021 7:53 am, Aleksei Voitylov wrote:
>> On Mon, 24 May 2021 06:24:15 GMT, David Holmes
>> wrote:
>>
>>>> Aleksei Voitylov has updated the pull request incrementally with
>>>> one additional com
On Mon, 24 May 2021 06:24:15 GMT, David Holmes wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibr
Peter, David,
I updated the PR to focus on solving the problem I originally intended
to solve that is observed in the wild - a deadlock when two different
libraries are being loaded. The case when the same library JNI_OnLoad
has FindClass with a circular dependency on loading the same library is
On Fri, 21 May 2021 15:49:09 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one a
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one
On Wed, 19 May 2021 18:47:52 GMT, Jorn Vernee wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix trailing whitespace
>
> src/java.base/share/classes/jdk/internal/loader
On Wed, 19 May 2021 16:29:33 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
On Wed, 19 May 2021 16:21:41 GMT, Aleksei Voitylov
wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incrementally with one a
Hi David, Mandy,
In the updated PR I removed the lock held during the load/unload calls.
Our testing confirmed that without that removal the deadlock can easily
be reproduced, even without signed jars. Now the lock is only held to
prevent races during access to "libraries" and
lates the names of
> all native libraries loaded - in line with class loading code, it is not
> explicitly cleared.
>
> Testing: jtreg and jck testing with no regressions. A new regression test
> was developed.
Aleksei Voitylov has updated the pull request incremental
Hi David,
On 12/05/2021 10:56, David Holmes wrote:
> Hi Aleksei,
>
> On 11/05/2021 11:19 pm, Aleksei Voitylov wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between
>> the two lock objects - a lock object associated with the
On Tue, 11 May 2021 13:10:30 GMT, Aleksei Voitylov
wrote:
> Please review this PR which fixes the deadlock in ClassLoader between the two
> lock objects - a lock object associated with the class being loaded, and the
> ClassLoader.loadedLibraryNames hash map, locked during the nativ
On Tue, 11 May 2021 13:28:16 GMT, Alan Bateman wrote:
>> Please review this PR which fixes the deadlock in ClassLoader between the
>> two lock objects - a lock object associated with the class being loaded, and
>> the ClassLoader.loadedLibraryNames hash map, locked during the native
>>
Please review this PR which fixes the deadlock in ClassLoader between the two
lock objects - a lock object associated with the class being loaded, and the
ClassLoader.loadedLibraryNames hash map, locked during the native library load
operation.
Problem being fixed:
The initial reproducer
d internal API" is the intended
> description as it indicates that a non-existent API is referenced.
>
> I created https://bugs.openjdk.java.net/browse/JDK-8265773 to fix this.
>
> thanks
> Mandy
>
> On 4/22/21 4:21 AM, Aleksei Voitylov wrote:
>> Hi,
>>
&g
Hi,
JDK-8213909 [1] (since JDK 12, backported into 11.0.11), aside from
bringing great additions to transitive module analysis, introduced a
slight change in output of jdeps:
jdk-11.0.11/bin/jdeps -s reactor-core-3.4.5.jar
reactor-core-3.4.5.jar -> jdk8internals
reactor-core-3.4.5.jar ->
On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov
wrote:
> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16.
>
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the
> runtime. One comes from default initialization of
On Tue, 23 Mar 2021 08:21:27 GMT, Alan Bateman wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix style
>
> Marked as reviewed by alanb (Reviewer).
Thanks Ioi, D
On Tue, 23 Mar 2021 06:47:50 GMT, Alan Bateman wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix style
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 156:
submit GitHub
> actions tests.
Aleksei Voitylov has updated the pull request incrementally with one additional
commit since the last revision:
fix style
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3131/files
- new: https://git.openjdk.java.net/jdk/pull/3131/
With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16.
After JDK-8253081 with CDS enabled two instances of empty layer appear in the
runtime. One comes from default initialization of
java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is
returned by
On Mon, 14 Sep 2020 06:30:50 GMT, Aleksei Voitylov
wrote:
>> Marked as reviewed by dholmes (Reviewer).
>
> thank you Alan, Erik, and David! When the JEP becomes Targeted, I'll use this
> PR to integrate the changes.
I added the contributors that could be found in the portola
On Mon, 14 Sep 2020 04:18:39 GMT, David Holmes wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8247589: Implementation of Alpine Linux/x64 Port
>
> Marked as reviewed by dholm
On Tue, 8 Sep 2020 23:44:58 GMT, David Holmes wrote:
>> Aleksei Voitylov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8247589: Implementation of Alpine Linux/x64 Port
>
> make/autoconf/platform.m4 l
est the
> integration to happen only after the JEP is
> targeted. I guess this step is now done by typing "slash integrate" in a
> comment.
> - we can pause the review process now until the JEP is targeted.
>
> In the first case I'm kindly asking the Reviewers who al
into tests with @requires
vm.musl | os.family = "aix" and with @requires !vm.musl & os.family !=
"aix".
-Aleksei
On 04/09/2020 15:51, Aleksei Voitylov wrote:
> Alan,
>
> in this case I'm leaning towards a new class jdk.test.lib.LibcHelper
> with a nat
do you think?
-Aleksei
On 04/09/2020 12:08, Alan Bateman wrote:
> On 04/09/2020 10:00, Alan Bateman wrote:
>> On 04/09/2020 08:55, Aleksei Voitylov wrote:
>>> :
>>> Tests tools/launcher/Test7029048.java and
>>> tools/launcher/ExecutionEnvironment.java need to ch
Hi Erik, Magnus, Mikael, Nick, David, and Alan,
thank you for looking into it. I grouped together all the comments in
one response to avoid polluting the mailing lists. Here is an updated
version of the patch which addresses the comments:
http://cr.openjdk.java.net/~avoitylov/webrev.8247589.06/
Hi,
JEP 386 is now Candidate [1] and as we resolved all outstanding issues
within the Portola project I'd like to ask for comments from HotSpot,
Core Libs (changes in libjli/java_md.c), and Build groups before moving
the JEP to Proposed to Target:
Thanks Alexey for the review!
Unless we need another review, would you sponsor the change?
Thanks,
-Aleksei
On 21/07/2020 21:27, Alexey Semenyuk wrote:
> Hi Aleksei,
>
> Looks good!
>
> - Alexey
>
> On 7/21/2020 11:42 AM, Aleksei Voitylov wrote:
>> Hi,
>>
Thanks Mandy, that would be much appreciated!
On 23/07/2020 07:24, Mandy Chung wrote:
> Hi Aleksei,
>
> Looks good. I can sponsor this.
>
> Mandy
>
> On 7/22/20 1:32 AM, Aleksei Voitylov wrote:
>> Hi Mandy,
>>
>> here is the webrev which addresses your com
ledTest list to the run method as an argument.
>
> Typo in line 90: s/bug got/but got/
>
> Otherwise, looks okay.
>
> Mandy
>
> On 7/21/20 10:37 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> gently reminiding about this simple test refactoring. The patch still
>&g
Hi,
gently reminiding about this simple test refactoring. The patch still
applies cleanly.
-Aleksei
On 24/06/2020 11:44, Aleksei Voitylov wrote:
> Hi,
>
> I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
> logic easier to follow and remove some magic numbers f
ad cfg file at all, but pass command line arguments
> as is in JLI_Launch().
> Let my think on ideas how to address this.
>
> - Alexey
>
> On 6/26/2020 7:16 AM, Aleksei Voitylov wrote:
>> Hi Alexey,
>>
>> Thank you for looking into it. As far as using
ame executable as the
> current one and if this is the case don't read data from the config
> file but pass executable arguments as is in JLI_Launch() call?
>
> - Alexey
>
> On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
>> Hi,
>>
>> There are systems that upd
Hi,
There are systems that update LD_LIBRARY_PATH or directly return
JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c
file to request re-execution of the current executable. This leads to
the fact that jpackage application adds some provided arguments twice.
Bug:
Hi,
I'd like to refactor test/jdk/tools/launcher/Test7029048.java, make the
logic easier to follow and remove some magic numbers from the test:
JBS: https://bugs.openjdk.java.net/browse/JDK-8247592
Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8247592.01/
Testing: the test passes on
On 16/10/2018 02:25, Kim Barrett wrote:
On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov
wrote:
Kim,
If you were suggesting to just proceed with the change without giving a
sufficient lead time for the ports that were willing to upgrade to do so, that
sounds very alarming.
What
time frame. There are several
issues that we still need to diagnose, but this does not look like a
blocker.
-Aleksei
On 11/10/2018 22:23, Kim Barrett wrote:
On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov
wrote:
Kim,
Let's not underestimate the importance of continuous testing throughout
esting ARM
with 7.3 and will report on success.
-Aleksei
On 08/10/2018 22:34, Kim Barrett wrote:
On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov
wrote:
Kim,
from an ARM port perspective, the stable GCC version is 4.9. The port compiles
with stock GCC 7.3 but a lot of testing is required before mov
JDK 12 is a little too optimistic.
GCC x86 is a lot more stable than for ARM32 and AARCH64.
-Aleksei
On 05/10/2018 00:09, Kim Barrett wrote:
On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov
wrote:
Kim,
Thank you for posting this. It's an important step to make. I wanted to clarify
a couple
Kim,
Thank you for posting this. It's an important step to make. I wanted to
clarify a couple of points:
1. Since this is infrastructure JEP, is the version of JDK which will
undergo such changes going to be some future version or does it apply to
past versions as well? I'm concerned with
64 matches
Mail list logo
