Hi Calvin, this looks good to me, too.
Thanks
- Ioi
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a
Hi Tagir,
A few quick thoughts on this.
There does seem to be a conceptual hole here. Most collections implementations
have an obvious interface that provides a reasonable abstraction of that
implementation. However, one is "missing" for LinkedHashSet, since there's no
interface more
On 28/04/2020 10:01 am, David Holmes wrote:
On 28/04/2020 9:37 am, Ioi Lam wrote:
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
There's a way to pass properties
Hi Thomas,
Thanks for looking into this in detail.
Actually the problem is not as bad as you think (I hope ). First of
all, this patch is intended for -Xshare:dump only (aka static CDS
archive). Dynamic CDS archive (-XX:ArchiveClassesAtExit) is much harder
to make deterministic because
On 28/04/2020 9:37 am, Ioi Lam wrote:
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
There's a way to pass properties from the VM that the user can't
override. I'll
Hi David & Jiangli,
Thanks for your comments.
I thought about using a system property, but the user can also specify
it like
java -Djdk.xshare.dump.salt=0 MyProgram
This would circumvent the calculation of ImmutableCollections.SALT32L
for normal execution. I am not sure if this is
Hi Lois,
Thanks for your review!
Calvin
On 4/27/20 3:22 PM, Lois Foltan wrote:
Looks good Calvin.
Lois
On 4/27/2020 3:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to
On 4/27/20 2:42 PM, Remi Forax wrote:
Hi Maurizio, Mandy,
In
https://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev/src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java.udiff.html,
using a condy inside a static init make me sad,
using a late loading constant
Looks good Calvin.
Lois
On 4/27/2020 3:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shared app/platform class
Hi Mandy,
Thanks for your review!
Calvin
On 4/27/20 2:39 PM, Mandy Chung wrote:
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of
I do, however, see two problems.
1.) If the --icon option value points to a non-existent file - jpackage
will use the default icon without any warning, even if --verbose is used.
2.) If a dmg is created with a non default icns file (at least some, may
be size dependent) , the Applications
Hi Maurizio, Mandy,
In
https://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev/src/java.base/share/classes/java/lang/invoke/MemoryAccessVarHandleGenerator.java.udiff.html,
using a condy inside a static init make me sad,
using a late loading constant to early load it in the static init seems
On 4/27/20 3:41 PM, Andy Herrick wrote:
I can see this problem on Mac using .icns file, but I don't see any
similar problem on windows, using .ico format.
my mistake - was testing the wrong app (one without --icon option)
I cannot reproduce this even on Mac - can you show your complete
On 4/27/20 12:21 PM, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading
a shared app/platform class originated from the module
Looks OK to me. Thanks for the update.
Naoto
On 4/27/20 11:19 AM, Kiran Ravikumar wrote:
Hi Martin and Andrew,
Thanks for the review and providing a direction towards updating the
translations.
Here is an updated webrev with the changes:
I can see this problem on Mac using .icns file, but I don't see any
similar problem on windows, using .ico format.
/Andy
On 4/27/2020 3:03 PM, jjk wrote:
Tried various forms of
--icon Iconfile.icns
--resource-folder folder_name
etc, but 'am still getting default images for dmg and app (java
JBS: https://bugs.openjdk.java.net/browse/JDK-8241815
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8241815/webrev.00/
This change is to avoid java up call of definePackage() while loading a
shared app/platform class originated from the module image since the
packages from module image are
Tried various forms of
--icon Iconfile.icns
--resource-folder folder_name
etc, but 'am still getting default images for dmg and app (java snowman)
and same for windows version jdk.
What is the right way to change this behavior of jpackage (tried both open
jdk-15 EA and Jdk-14.1)
Thanks in
Thanks. This looks good.
How the tzdata updates get done has always been a mystery to me.
If you've written any helper scripts or process docs, checking those
in as well (but which directory?) might be useful.
(I maintain such things at Google, but they are not very useful for
you - too full of
Hi Martin and Andrew,
Thanks for the review and providing a direction towards updating the
translations.
Here is an updated webrev with the changes:
http://cr.openjdk.java.net/~kravikumar/8243541/webrev/
All associated tests pass. Please let me know if they look alright.
Thanks,
Kiran
+1.
Indeed, the resulting javadoc was fine :-)
Best,
Joe
On 4/27/2020 9:36 AM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
---
+1
On 4/27/20 12:36 PM, naoto.s...@oracle.com wrote:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java
2020-04-27 09:09:14.0
On 27/04/2020 12:13, Kiran Ravikumar wrote:
> Hello All,
>
>
> Please review the patch for tzdata2020a integration into jdk.
>
> Release details can be found here:
>
> http://mm.icann.org/pipermail/tz-announce/2020-April/58.html
>
>
> Webrev:
Hello,
Please review this small doc fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8243664
Here is the diff:
---
--- old/src/java.base/share/classes/java/text/CompactNumberFormat.java
2020-04-27 09:09:14.0 -0700
+++
On 2020-04-27 17:16, Lance Andersen wrote:
Hi Claes,
The changes and the performance bump all look good and with the minor
change below helps the readability.
Thanks! Pushed.
/Claes
Thank you for using your performance expertise to improve this area.
Best
Lance
On Apr 27, 2020, at 6:11
Hi Claes,
The changes and the performance bump all look good and with the minor change
below helps the readability.
Thank you for using your performance expertise to improve this area.
Best
Lance
> On Apr 27, 2020, at 6:11 AM, Claes Redestad wrote:
>
>
>
> On 2020-04-27 11:49, Volker
Hi Kiran,
Thanks for working on this update so promptly.
The innocent renaming of America/Godthab to America/Nuuk is causing much
trouble.
Since it's a renaming, both names remain and I expected them to have the
same metadata.
So I expected the entries in TimeZoneNames.java and the translations
Another iteration, which addresses the following issues:
* wrong copyright headers in certain tests
* issue with TestNative when running in debug mode caused by mismatched
malloc/os::free (contributed by Jorn)
* clarify javadoc of MemoryHandles::withStride
* improved implementation of
Hello All,
Please review the patch for tzdata2020a integration into jdk.
Release details can be found here:
http://mm.icann.org/pipermail/tz-announce/2020-April/58.html
Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/
Bug:
Thank you, Sundar.
On Mon, Apr 27, 2020 at 6:49 PM wrote:
>
> Hi,
>
> Looks good. I'll sponsor this fix.
>
> Thanks
>
> -Sundar
>
> On 27/04/20 4:15 pm, Ao Qi wrote:
> > Thanks, Sundar!
> >
> > I updated a new webrev (patch is the same, only hg commit info was
> > added):
Hi,
Looks good. I'll sponsor this fix.
Thanks
-Sundar
On 27/04/20 4:15 pm, Ao Qi wrote:
Thanks, Sundar!
I updated a new webrev (patch is the same, only hg commit info was
added): http://cr.openjdk.java.net/~aoqi/8242846/webrev.02/
Could someone help to sponsor this?
Thanks,
Ao Qi
On Mon,
Thanks, Sundar!
I updated a new webrev (patch is the same, only hg commit info was
added): http://cr.openjdk.java.net/~aoqi/8242846/webrev.02/
Could someone help to sponsor this?
Thanks,
Ao Qi
On Mon, Apr 27, 2020 at 4:52 PM wrote:
>
> Looks good
>
> -Sundar
>
> On 27/04/20 12:24 pm, Ao Qi
On 2020-04-27 11:49, Volker Simonis wrote:
On Sun, Apr 26, 2020 at 11:34 PM Claes Redestad
wrote:
Hi again,
On 2020-04-24 21:22, Claes Redestad wrote:
It seems that 'getEntryHitUncached' is getting slightly slower with
your change while all the other variants get significantly faster. I
On Sun, Apr 26, 2020 at 11:34 PM Claes Redestad
wrote:
>
> Hi again,
>
> On 2020-04-24 21:22, Claes Redestad wrote:
> >> It seems that 'getEntryHitUncached' is getting slightly slower with
> >> your change while all the other variants get significantly faster. I
> >> don't think that's a problem,
Rethinking this a bit more I realize you need not addresses growing
monotonously but deterministic allocation: given a sequence of Metaspace
allocation operations (Metaspace::allocate(), Metaspace::deallocate(), and
collection of class loaders), the pointers returned
by Metaspace::allocate()
Looks good
-Sundar
On 27/04/20 12:24 pm, Ao Qi wrote:
On Sun, Apr 26, 2020 at 12:00 AM Alan Bateman wrote:
On 21/04/2020 04:58, Ao Qi wrote:
On 2020/4/20 下午9:27, Alan Bateman wrote:
On 20/04/2020 11:32, sundararajan.athijegannat...@oracle.com wrote:
Hi Alan,
I don't remember it now.
Hi Ioi,
On 2020-04-27 07:22, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8241071
http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
I can't really comment on the code changes, but I'd like to thank you
for the effort of getting a deterministic
On Mon, Apr 27, 2020 at 8:23 AM David Holmes
wrote:
> Hi Ioi,
>
> On 27/04/2020 3:22 pm, Ioi Lam wrote:
> > https://bugs.openjdk.java.net/browse/JDK-8241071
> >
> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
> >
> >
> > The goal is to for "java -Xshare:dump" to
Hi Ioi,
Please don't do this :)
First off, how would this work when dumping with UseCompressedClassPointers
off? In that case allocation would be relegated to non-class metaspace
which cannot guarantee that kind of address stability.
Even in class space, I do not think you can guarantee
Hi Alan,
Thank you for the review. May I ask your help for sponsoring this fix?
Best Regards,
Toshio Nakamura
Alan Bateman wrote on 2020/04/24 17:50:39:
> On 24/04/2020 09:33, Toshio 5 Nakamura wrote:
> > Hi all,
> >
> > Please review this fix.
> > Also, I'd like to ask a sponsor of the
On Sun, Apr 26, 2020 at 12:00 AM Alan Bateman wrote:
>
> On 21/04/2020 04:58, Ao Qi wrote:
> >
> > On 2020/4/20 下午9:27, Alan Bateman wrote:
> >> On 20/04/2020 11:32, sundararajan.athijegannat...@oracle.com wrote:
> >>> Hi Alan,
> >>>
> >>> I don't remember it now. Likely a mistake. The changeset
Hi Ioi,
On 27/04/2020 3:22 pm, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8241071
http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/
The goal is to for "java -Xshare:dump" to produce deterministic contents in
the CDS archive that depend only on the
42 matches
Mail list logo
