Good morning!
On 4/7/22 23:59, Kasper Nielsen wrote:
Hi Michael,
I don't really have an opinion on how you obtain a logger. But one
particular
use-case I've had was that I would like to perform some access checks based
on the module of the caller. Something similar to how Panama checks for
During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is
usually null. However, if a signed class is loaded, `resourceCache` will point
to a `java.lang.ref.SoftReference`. Although rare (we have never seen this
during our testing), it's possible for `resourceCache.discovered` to
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>>
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>>
> Optimizes the divideUnsigned() and remainderUnsigned() methods in
> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
> change shows 3x improvement for Integer methods and upto 25% improvement for
> Long. This change also implements the DivMod optimization which fuses
>
On Wed, 6 Apr 2022 00:45:37 GMT, Vladimir Kozlov wrote:
>> Thanks for suggesting the enhancement. This enhancement will be implemented
>> as a part of https://bugs.openjdk.java.net/browse/JDK-8282365
>
> You do need `Ideal()` methods at least to check for dead code.
Added the Ideal() methods
On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add error msg for jtreg test
>
> I have few comments.
Hi Vladimir (@vnkozlov),
Incorporated all the
> Optimizes the divideUnsigned() and remainderUnsigned() methods in
> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
> change shows 3x improvement for Integer methods and upto 25% improvement for
> Long. This change also implements the DivMod optimization which fuses
>
Hi Hiran,
Thank you for providing all the details!
I can see two separate issues with jpackage:
1. jpackage reports NPE if it can't figure out the package name from
the supplied application image. It should issue a helpful error message
instead
2. jpackage fails to populate application image
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's
On Thu, 7 Apr 2022 20:02:51 GMT, Alan Bateman wrote:
>> Examples added in latest commit.
>
> I see you've added a comment on each example too, I think this really helpers
> readers to see how they can be used.
>
> The class description of both Integer and Long have an implementation note
>
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote:
> This is to upgrade the CLDR data from version 39 to version 41 which was
> released yesterday. The vast majority of the changes are basically replacing
> the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
> v41's
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote:
>> This is an early review of changes to better model JVM access flags, that is
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>>
>> Language level modifiers and JVM level access flags are closely related, but
>>
>
> Hi Kasper,
>
> sorry to jump in here as an uninvolved onlooker, but I can't resist.
> I really don't see why this should matter. Getting the caller class is a
> rare edge case that you just do in exceptional situations; most often
> it's more for debugging or something.
>
> What users really
This is to upgrade the CLDR data from version 39 to version 41 which was
released yesterday. The vast majority of the changes are basically replacing
the CLDR data, along with tools/testcase alignments. Here is the link to CLDR
v41's release notes:
C and C++ are harder to read as a side effect of pre-processor macros.
IMHO, Java's lack of pre-processor macros simplifies the language and
improves readability.
On 4/7/2022 9:01 PM, Ralph Goers wrote:
> I mentioned this same concern back in 2017 when the Sun Reflection
> class was removed.
> Created a test called NullCallerGetResource to test
> Module::getResourceAsStream and Class::getResourceAsStream from the native
> level.
>
> At the java level the test builds a test module called 'n' which opens the
> package 'open' to everyone. There is also a package 'closed' which is
Perhaps https://bugs.openjdk.java.net/browse/JDK-4515935 for the MemoryHandler
could be used to determine if StackWalker is fast enough for the lowest rung on
the StackWalker performance ladder. Currently the MemoryHandler doesn't not
infer the caller and the target handler sees the callsite
On Thu, 7 Apr 2022 18:23:50 GMT, Paul Sandoz wrote:
>> src/java.base/share/classes/java/lang/Integer.java line 1781:
>>
>>> 1779: * All the upper remaining bits of the compressed value are set
>>> 1780: * to zero.
>>> 1781: *
>>
>> Following Alan's comment, I suggest the
Hello Alex,
thank you for coming back. We now have four different cases just for
the second build step (appimage->deb). Let me first give you an
overview:
My Desktop (OpenJDK 16): My Command, Your command
Github (OpenJDK 17): My command, Your command
On Github I started using OpenJDK11,
I mentioned this same concern back in 2017 when the Sun Reflection
class was removed.
In Log4j’s case there are two places that accessing the stack comes into play:
1. Obtaining a Logger .
2. Logging an event and including the caller’s location information.
To be honest, what sucks for Logging
On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which now marks `CollectionView` as
> a `sealed` class with only `EntrySetView`, `KeySetView` and `ValuesView` as
> the sub-classes? This change corresponds to
>
On Wed, 6 Apr 2022 18:22:45 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Fix typo.
>> - Provide examples.
>
> src/java.base/share/classes/java/lang/Integer.java line 1781:
>
>> 1779: *
> Add support to compress bits and expand bits of `int` and `long` values, see
> Hacker's Delight (2nd edition), section 7.4.
>
> Compressing or expanding bits of an `int` or `long` value can be composed to
> enable general permutations, and the "sheep and goats" operation (SAG) see
> Hacker's
Hi Hiran,
My apologies for not replying to your previous email. In that particular
case the problem seems to be in missing "--name" cli option on the
second jpackage command line ($JAVA_HOME/bin/jpackage --app-image
build/app-image --verbose --dest build) that is supposed to build .deb
Some loggers do need to find the location of the log statement (class and line
where the logger is used not where it is instantiated).
for those (it makes loggers more useful) getting the call site is time
critical even if they are not in tight performance critical loops.
But it actually does
On 4/7/22 19:27, Kasper Nielsen wrote:
nope, see my previous mail to Ceki, the VM is cheating here if it can
inline the call to MethodHandles.lookup()
Does how the VM cheats really matter? The fact is that the code in the JDK
can
get the calling class and implement something like
>
> nope, see my previous mail to Ceki, the VM is cheating here if it can
> inline the call to MethodHandles.lookup()
>
Does how the VM cheats really matter? The fact is that the code in the JDK
can
get the calling class and implement something like MethodHandles.lookup() so
it takes ~3 ns. If
> Add support to compress bits and expand bits of `int` and `long` values, see
> Hacker's Delight (2nd edition), section 7.4.
>
> Compressing or expanding bits of an `int` or `long` value can be composed to
> enable general permutations, and the "sheep and goats" operation (SAG) see
> Hacker's
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8234128
>
> My initial attempt had too many bad side-effects. This latest fix only tries
> to suppress the warning message.
This pull request has now been integrated.
Changeset: d6f01e9d
Author:
On Thu, 7 Apr 2022 05:52:24 GMT, Alan Bateman wrote:
> Tim - this creates a conflict between the spec and implementation, the
> changes to the 2-arg isOpen method need to be dropped so that it continues to
> throw NPE if module is null.
okay
-
PR:
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8234128
>
> My initial attempt had too many bad side-effects. This latest fix only tries
> to suppress the warning message.
Looks good to me.
Yeah, the loop seems like it would behave the same way
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8234128
>
> My initial attempt had too many bad side-effects. This latest fix only tries
> to suppress the warning message.
I recall that Max said the intermediate was not necessary. Maybe he can
On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeliński wrote:
> This patch adds missing `r` in `string`s
This pull request has now been integrated.
Changeset: 5bafcfdc
Author:Daniel Jeliński
URL:
https://git.openjdk.java.net/jdk/commit/5bafcfdc171b5a514ecf620703e77fa2f4a49c58
Stats:
On Thu, 7 Apr 2022 14:01:53 GMT, Claes Redestad wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> I experimented with this and drafted a few microbenchmarks along and a
> micro-optimization
On Wed, 6 Apr 2022 17:39:48 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 145:
>
>> 143:
>> 144: int i
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote:
> https://bugs.openjdk.java.net/browse/JDK-8234128
>
> My initial attempt had too many bad side-effects. This latest fix only tries
> to suppress the warning message.
test/jdk/sun/security/tools/jarsigner/warnings/AliasNotInStoreTest2.java
On Wed, 6 Apr 2022 21:57:44 GMT, Paul Sandoz wrote:
>> Add support to compress bits and expand bits of `int` and `long` values, see
>> Hacker's Delight (2nd edition), section 7.4.
>>
>> Compressing or expanding bits of an `int` or `long` value can be composed to
>> enable general
Rémi, Jason, Steven, Kasper,
Thank you all for your thoughtful feedback.
I forgot to mention that in addition to obtaining the appropriate logger
by inferring caller class, the caller class may also be a data point
written with each logging event, aka LogRecord.
If the cost of writing a log
> From: "Kasper Nielsen"
> To: "Remi Forax"
> Cc: "Ceki Gülcü" , "core-libs-dev"
>
> Sent: Thursday, April 7, 2022 2:42:46 PM
> Subject: Re: fast way to infer caller
> On Thu, 7 Apr 2022 at 13:33, Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:
>> - Original
On Thu, 7 Apr 2022 00:56:42 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package
On Thu, 7 Apr 2022 at 13:33, Remi Forax wrote:
> - Original Message -
> > From: "Kasper Nielsen"
> > To: "Ceki Gülcü"
> > Cc: "core-libs-dev"
> > Sent: Thursday, April 7, 2022 1:53:33 PM
> > Subject: Re: fast way to infer caller
>
> >>
> >> MethodHandles.lookup().lookupClass() looks
- Original Message -
> From: "Kasper Nielsen"
> To: "Ceki Gülcü"
> Cc: "core-libs-dev"
> Sent: Thursday, April 7, 2022 1:53:33 PM
> Subject: Re: fast way to infer caller
>>
>> MethodHandles.lookup().lookupClass() looks very promising except that
>> there is no way to specify the depth.
>
> MethodHandles.lookup().lookupClass() looks very promising except that
> there is no way to specify the depth.
>
> I am looking for a method to obtain the Nth caller at a cost of around
> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
> for this use case?
>
Hi Ceki,
I
On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which now marks `CollectionView` as
> a `sealed` class with only `EntrySetView`, `KeySetView` and `ValuesView` as
> the sub-classes? This change corresponds to
>
> Despite the hash value being cached for Strings, computing the hash still
> represents a significant CPU usage for applications handling lots of text.
>
> Even though it would be generally better to do it through an enhancement to
> the autovectorizer, the complexity of doing it by hand is
Hi there.
I have another case where running jpackage emits
Bundler DEB Bundle failed because of java.lang.NullPointerException:
Cannot invoke "java.lang.CharSequence.length()" because "this.text" is
null
I have never experienced NullPointerExceptions in other JDK tools.
Seems to me JPackage is
47 matches
Mail list logo
