On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
On Wed, 5 Feb 2025 19:39:30 GMT, Dean Long wrote:
> I think we could go even further and eventually fold the JNI critical region
> into the existing safepoint mechanism.
@dean-long you seem to be forgetting why it was folded out in the first place.
:) This was performance critical JNI code wh
On Wed, 5 Feb 2025 14:04:18 GMT, Amit Kumar wrote:
>> Thanks David and Johan for the reviews.
>
> Hi @coleenp,
>
> I am repeating the message from Theresa, since she is part of OpenJ9 and
> can't accept OpenJDK Terms:
>
>
> `serviceability/jvmti/RedefineClasses/RedefineVerifyError.java` I
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Thu, 12 Dec 2024 10:16:01 GMT, Viktor Klang wrote:
>> @viktorklang-ora `@Stable` is not about how the field was set, but about the
>> JIT observing a non-default value at compile time. If it observes a
>> non-default value, it can treat it as a compile time constant.
>
> @DanHeidinga Great
On Tue, 4 Feb 2025 14:43:51 GMT, Coleen Phillimore wrote:
>> The Class.getModifiers() method is implemented as a native method in
>> java.lang.Class to access a field that we've calculated when creating the
>> mirror. The field is final after that point. The VM doesn't need it
>> anymore, so
On Wed, 5 Feb 2025 01:10:39 GMT, Dean Long wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix copyright and param name
>
> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
>
>> 71: publ
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
On Wed, 5 Feb 2025 14:41:39 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
On Thu, 21 Nov 2024 12:13:50 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Reduce test, fix bug in verifier, move and add comments to
>> is_eligible_for_verification.
>
> Thanks David
On Tue, 4 Feb 2025 09:05:35 GMT, Thomas Schatzl wrote:
>> Albert Mingkun Yang has updated the pull request with a new target base due
>> to a merge or a rebase. The incremental webrev excludes the unrelated
>> changes brought in by the merge/rebase. The pull request contains four
>> additional
On Wed, 5 Feb 2025 14:38:45 GMT, Albert Mingkun Yang wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and
>> Parallel.
>>
>> GCLocker prevents GC when Java threads are in a critical region (i.e.,
>> calling JNI critical APIs). JDK-7129164 introduces an optimization t
> Here is an attempt to simplify GCLocker implementation for Serial and
> Parallel.
>
> GCLocker prevents GC when Java threads are in a critical region (i.e.,
> calling JNI critical APIs). JDK-7129164 introduces an optimization that
> updates a shared variable (used to track the number of threa
On Wed, 5 Feb 2025 19:42:02 GMT, Coleen Phillimore wrote:
>> test/micro/org/openjdk/bench/java/lang/reflect/Clazz.java line 73:
>>
>>> 71: public int getAppArrayModifiers() {
>>> 72: return clazzArray.getClass().getModifiers();
>>> 73: }
>>
>> I'm guessing this is the benchmark
On Wed, 5 Feb 2025 15:51:25 GMT, Daniel Fuchs wrote:
>> java.util.logging.LoggingMXBean and
>> java.util.logging.LogManager::getLoggingMXBean are deprecated since
>> JDK-8139982 in JDK 9.
>>
>> These deprecations should be uprated to state they are for future removal.
>>
>> java.util.logging.
> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
feedback
--
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote:
> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>
> JDK-8348190: Framework for tracing makefile inclusion and parsing
>
> The above issue caused problems in the Oracle closed builds and so needs to
> be backed out until that
On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote:
> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>
> JDK-8348190: Framework for tracing makefile inclusion and parsing
>
> The above issue caused problems in the Oracle closed builds and so needs to
> be backed out until that
On Thu, 6 Feb 2025 02:48:21 GMT, Mikael Vidstedt wrote:
>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>>
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>>
>> The above issue caused problems in the Oracle closed builds and so needs to
>> be backed out un
On Thu, 6 Feb 2025 02:01:47 GMT, Joe Darcy wrote:
>> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>>
>> JDK-8348190: Framework for tracing makefile inclusion and parsing
>>
>> The above issue caused problems in the Oracle closed builds and so needs to
>> be backed out until th
On Thu, 6 Feb 2025 01:32:51 GMT, David Holmes wrote:
> This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
>
> JDK-8348190: Framework for tracing makefile inclusion and parsing
>
> The above issue caused problems in the Oracle closed builds and so needs to
> be backed out until that
This reverts commit 61465883b465a184e31e7a03e2603d29ab4815a4.
JDK-8348190: Framework for tracing makefile inclusion and parsing
The above issue caused problems in the Oracle closed builds and so needs to be
backed out until that is addressed.
Thanks.
-
Commit messages:
- Revert "
On Wed, 5 Feb 2025 20:23:05 GMT, Dean Long wrote:
>> Name Cnt Base Error Test Error Unit Change
>> getAppArrayModifiers 30 0.923 ± 0.004 1.260 ± 0.001 ns/op 0.73x (p
>> = 0.000*)
>> getAppArrayModifiersFinal 30 0.922 ± 0.000 1.260 ± 0.001 ns/op 0.73x (p
27 matches
Mail list logo
