On Sat, 6 Jul 2024 00:15:04 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
>> I hope you can revie
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it patiently.
>
>
> Improved performance includes the
The current HexFormat defines an Enum to represent LowerCase and UpperCase
class HexFormat {
private enum Case {
LOWERCASE,
UPPERCASE
}
}
This will cause the JVM to load one more class when it starts, which can be
seen as follows
public class Startup {
public stat
On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
>> I hope you can revie
On Thu, 4 Jul 2024 10:08:30 GMT, Kevin Walls wrote:
> There are two similarly names tests.
> Recently:
> JDK-8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed
> with CPU time out of expected range
> ...made a simple change to try and avoid noisy test failures. The same fix
On Fri, 5 Jul 2024 20:43:51 GMT, Shaojin Wen wrote:
>> String.format is widely used, and improving its performance is very
>> meaningful. This PR can significantly improve the performance of
>> String.format. Sorry, there are many changes, which will take a lot of time.
>> I hope you can revie
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it patiently.
>
>
> Improved performance includes the
On Fri, 5 Jul 2024 18:56:58 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request incrementally with four additional
>> commits since the last revision:
>>
>> - use unknownFormatConversion method construct
>> UnknownFormatConversionException
>> - uppercase static final field nam
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it patiently.
>
>
> Improved performance includes the
On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen wrote:
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it
Please review this patch that address the reflection member filtering flaws.
1. Remove a pointless bootstrap check to ensure no filter is accidentally
bypassed due to class-loading order.
2. Clarify the scenarios for filtering, and the correct filter actions for each
scenario.
3. Remove the filt
On Fri, 5 Jul 2024 15:40:24 GMT, Shaojin Wen wrote:
> String.format is widely used, and improving its performance is very
> meaningful. This PR can significantly improve the performance of
> String.format. Sorry, there are many changes, which will take a lot of time.
> I hope you can review it
String.format is widely used, and improving its performance is very meaningful.
This PR can significantly improve the performance of String.format. Sorry,
there are many changes, which will take a lot of time. I hope you can review it
patiently.
Improved performance includes the following:
##
On Tue, 2 Jul 2024 02:13:50 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 2 Jul 2024 14:04:52 GMT, Shaojin Wen wrote:
>> We need a String format solution with good performance. String Template was
>> once expected, but it has been removed. j.u.Formatter is powerful, but its
>> performance is not good enough.
>>
>> This PR implements a subset of j.u.Formatter
On Fri, 28 Jun 2024 13:09:19 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java
>> line 43:
>>
>>> 41: * The private serialization bytecode generator used by {@code
>>> sun.misc.ReflectionFactory}.
>>> 42: */
>>> 43: final class Ser
On Fri, 28 Jun 2024 22:03:36 GMT, ExE Boss wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was expe
On Mon, 1 Jul 2024 12:58:16 GMT, David M. Lloyd wrote:
>> My hope is that the method handle would be more easily inlined when each one
>> is a separate constant. I'd feel less confident that this would be the case
>> if I indirected through `List`. I think it would also increase the size of
>>
On Mon, 1 Jul 2024 12:46:18 GMT, David M. Lloyd wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 441:
>>
>>> 439: }
>>> 440:
>>> 441: return
>>> SerializationBytecodeGenerator.defaultReadObjectForSerialization(cl);
>>
>> How likely is
On Mon, 1 Jul 2024 05:35:37 GMT, Chen Liang wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was exp
On Fri, 28 Jun 2024 14:04:13 GMT, David M. Lloyd wrote:
>> Indeed, if you look at the previous revision, that's how I implemented it.
>> However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in
>> order to generate a nestmate class and accessors for private members on the
>> cl
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
On Thu, 27 Jun 2024 08:08:13 GMT, Alan Bateman wrote:
>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
>> support for functionality required to continue to support IIOP and custom
>> serializers in light of additional module-based restrictions on reflection.
>> It was
On Mon, 1 Jul 2024 13:16:39 GMT, David M. Lloyd wrote:
> According to https://wiki.openjdk.org/display/csr/CSR+FAQs, only changes to
> public and exported APIs in the `jdk.*`, `java.*`, and `javax.*` packages
> need a CSR. This PR changes public and exported APIs in the `sun.misc`
> package, a
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd wrote:
> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added
> support for functionality required to continue to support IIOP and custom
> serializers in light of additional module-based restrictions on reflection.
> It was ex
Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support
for functionality required to continue to support IIOP and custom serializers
in light of additional module-based restrictions on reflection. It was expected
that these libraries would use `sun.misc.Unsafe` in order t
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule wrote:
>> Similar to how `MethodHandle#invoke(Exact)` methods are already handled,
>> this change adds special casing for `VarHandle.{access-mode}` methods.
>>
>> The exception message is less exact, but I think that's acceptable.
>
> Hannes Greule
On Fri, 5 Jul 2024 13:44:06 GMT, Jorn Vernee wrote:
>> @JornVernee Here are a few traces for comparison:
>> https://gist.github.com/5d441ab2159833e808303d1accb66ee8
>>
>> In all cases, the entire stacktrace is retained; this ClassNotFoundException
>> has the `MethodTypeDescImpl::resolveConstan
On Fri, 5 Jul 2024 14:01:59 GMT, Per Minborg wrote:
>> This PR proposes to retain the read-only state when any of the
>> `MemorySegment::reinterpret` methods is called.
>>
>> Previously, the read-only state was lost and the returned `MemorySegment`
>> was always writable regardless of the orig
> This PR proposes to retain the read-only state when any of the
> `MemorySegment::reinterpret` methods is called.
>
> Previously, the read-only state was lost and the returned `MemorySegment` was
> always writable regardless of the original segment's read-only state.
Per Minborg has updated th
On Wed, 3 Jul 2024 19:11:34 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
>> line 228:
>>
>>> 226: mtype = mt;
>>> 227: } catch (TypeNotPresentException ex) {
>>> 228: throw (ClassNotFoundException) ex.getCaus
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
> `--
This patch expands the use of a hash table for secondary superclasses
to the interpreter, C1, and runtime. It also adds a C2 implementation
of hashed lookup in cases where the superclass isn't known at compile
time.
HotSpot shared runtime
--
Building hashed secondary tables is
On Wed, 3 Jul 2024 21:43:05 GMT, Shaojin Wen wrote:
> In JDK 21, StringBuilder added a repeat method, which can be used to improve
> j.u.Formatter#trailingZeros
This pull request has now been integrated.
Changeset: 194425d7
Author:Shaojin Wen
Committer: Chen Liang
URL:
https://git
37 matches
Mail list logo
