On Thu, 7 Apr 2022 22:44:19 GMT, Ioi Lam wrote:
> 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
On Tue, 15 Mar 2022 17:08:27 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry
On Fri, 11 Mar 2022 06:55:23 GMT, Ioi Lam wrote:
>> This patch makes the result of "java -Xshare:dump" deterministic:
>> - Disabled new Java threads from launching. This is harmless. See comments
>> in jvm.cpp
>> - Fixed a problem in hashtable ordering in heapShared.cpp
>> - BasicHashtableEntry
On Wed, 19 Jan 2022 05:47:57 GMT, Ioi Lam wrote:
>> **Background:**
>>
>> In the Java Language, Enums can be tested for equality, so the constants in
>> an Enum type must be unique. Javac compiles an enum declaration like this:
>>
>>
>> public enum Day { SUNDAY, MONDAY ... }
>>
>>
>> to
On Fri, 17 Sep 2021 02:17:09 GMT, Remilia Scarlet
wrote:
>> The test assumes that it always runs on 64-bit platform and
>> classes_nocoops.jsa is always created.
>> It's a test bug. The test should only expect classes_nocoops.jsa exists if
>> it's running on a supported 64-bit platform.
>>
On Thu, 16 Sep 2021 17:53:25 GMT, Mandy Chung wrote:
> > The fix in the test case seems fine to me.
>
> This test may fail in other cases. We should prepare for those cases in this
> fix:
>
> ```
> if (!Platform.isDefaultCDSArchiveSupported() && !Platform.isAArch64()))
> throw new
On Thu, 16 Sep 2021 03:44:24 GMT, Remilia Scarlet
wrote:
>> The test assumes that it always runs on 64-bit platform and
>> classes_nocoops.jsa is always created.
>> It's a test bug. The test should only expect classes_nocoops.jsa exists if
>> it's running on a supported 64-bit platform.
>>
On Tue, 24 Aug 2021 17:21:20 GMT, Calvin Cheung wrote:
> Please review this trivial change for fixing the copyright year of the two
> files (jlink.properties and ImagePluginStack.java) which were modified
> unintentionally during the fix for JDK-8264322.
This pull request has
On Tue, 24 Aug 2021 17:35:50 GMT, Brian Burkhalter wrote:
>> Please review this trivial change for fixing the copyright year of the two
>> files (jlink.properties and ImagePluginStack.java) which were modified
>> unintentionally during the fix for JDK-8264322.
>
> I verified that in the commit
Please review this trivial change for fixing the copyright year of the two
files (jlink.properties and ImagePluginStack.java) which were modified
unintentionally during the fix for JDK-8264322.
-
Commit messages:
- 8272916: Copyright year was modified unintentionally in
On Tue, 24 Aug 2021 02:16:31 GMT, Mandy Chung wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @mlchung comments
>
> Thanks for creating a JBS issue. I'm okay to follow up the tes
On Wed, 18 Aug 2021 21:21:06 GMT, Calvin Cheung wrote:
> Please review this change for adding a `jlink` command line option
> `--generate-cds-archive` for generating CDS archives as a post processing
> step during the creation of a custom JDK image.
>
> Detai
On Fri, 20 Aug 2021 02:04:52 GMT, Mandy Chung wrote:
>> I'd prefer to leave it as is for now since it's in a test case and I don't
>> think the code is complex.
>
> This is fragile by setting `os.name`.
I've filed [JDK-8272868](https://bugs.openjdk.java.net/browse/JDK-8272868) to
follow-up
s.openjdk.java.net/browse/JDK-8269178).
>
> Testing:
>
> - [x] tiers 1,2 (including the new test)
Calvin Cheung has updated the pull request incrementally with one additional
commit since the last revision:
@mlchung comments
-
Changes:
- all: https://git.openjdk.java.n
On Wed, 18 Aug 2021 23:55:25 GMT, Mandy Chung wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @mlchung comments
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/builder/Defau
Please review this change for adding a `jlink` command line option
`--generate-cds-archive` for generating CDS archives as a post processing step
during the creation of a custom JDK image.
Details can be found in the corresponding CSR
On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote:
>> Hi, Please review
>> When using jcmd to dump shared archive, if the archive name exists, it
>> will be deleted first. If exception happens during dumping process, there is
>> no new archive created. This PR changes to first dump the
On Fri, 7 May 2021 00:02:56 GMT, Yumin Qi wrote:
>> test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java line 78:
>>
>>> 76: print2ln(test_count++ + " Set target dir not writable, do
>>> dynamic dump");
>>> 77: setKeepArchive(true);
>>> 78:
On Thu, 6 May 2021 21:37:35 GMT, Yumin Qi wrote:
>> Hi, Please review
>> When using jcmd to dump shared archive, if the archive name exists, it
>> will be deleted first. If exception happens during dumping process, there is
>> no new archive created. This PR changes to first dump the
On Tue, 1 Dec 2020 19:30:45 GMT, Calvin Cheung wrote:
> Please review this change which includes:
>
> - If the `jdk.internal.lambda.disableEagerInitialization`property is enabled,
> the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda
> proxy classes or to
he `initialize` (same as `!disableEagerInitialization`) to
> `LambdaProxyClassArchive.find` and eventually to the
> `JVM_LookupLambdaProxyClassFromArchive` function.
>
> Testing:
>
> - [x] all cds/appcds tests locally on linux-x64
>
> - [x] tiers 1 - 4 (in progress
he `initialize` (same as `!disableEagerInitialization`) to
> `LambdaProxyClassArchive.find` and eventually to the
> `JVM_LookupLambdaProxyClassFromArchive` function.
>
> Testing:
>
> - [x] all cds/appcds tests locally on linux-x64
>
> - [x] tiers 1 - 4 (in progress
On Tue, 1 Dec 2020 22:47:18 GMT, Ioi Lam wrote:
>> I can make a copy and put it under the
>> `open/test/hotspot/jtreg/runtime/cds/appcds/test-classes` dir. I'd still
>> need the `@compile` and would be something like `@compile
>> test-classes/LambdaEagerInitTest.java`.
>
> The `@compile` can
On Tue, 1 Dec 2020 22:19:55 GMT, Mandy Chung wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added a test
>
> test/hotspot/jtreg/runtime/cds/appcds/LambdaEa
he `initialize` (same as `!disableEagerInitialization`) to
> `LambdaProxyClassArchive.find` and eventually to the
> `JVM_LookupLambdaProxyClassFromArchive` function.
>
> Testing:
>
> - [x] all cds/appcds tests locally on linux-x64
>
> - [x] tiers 1 - 4 (in progress
On Tue, 1 Dec 2020 22:16:58 GMT, Mandy Chung wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added a test
>
> test/hotspot/jtreg/runtime/cds/appcds/LambdaEagerInit.java line 36:
On Tue, 1 Dec 2020 20:50:11 GMT, Claes Redestad wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added a test
>
> Looks good to me!
@mlchung, @iklam, @cl4es Thanks for
he `initialize` (same as `!disableEagerInitialization`) to
> `LambdaProxyClassArchive.find` and eventually to the
> `JVM_LookupLambdaProxyClassFromArchive` function.
>
> Testing:
>
> - [x] all cds/appcds tests locally on linux-x64
>
> - [x] tiers 1 - 4 (in progress
Please review this change which includes:
- If the `jdk.internal.lambda.disableEagerInitialization`property is enabled,
the `InnerClassLambdaMetafactory` will not involve CDS to archive lambda proxy
classes or to find them from an archive.
- Not passing the `initialize` (same as
On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung wrote:
> Before this change, the setting of the
> `jdk.internal.lambda.disableEagerInitialization` property was not captured
> during dumping of lambda proxy classes. There's a workaround in
> `LambdaProxyClassArchive.find`, i
On Thu, 19 Nov 2020 16:09:41 GMT, Claes Redestad wrote:
>> Hi Claes,
>>
>> Thanks for taking a look.
>>
>> So should I keep the following `!initialize` check in
>> LambdaProxyClassArchive?
>> 109 if (!loadedByBuiltinLoader(caller) || !initialize ||
>> 110
On Thu, 19 Nov 2020 19:42:51 GMT, Yumin Qi wrote:
>> Before this change, the setting of the
>> `jdk.internal.lambda.disableEagerInitialization` property was not captured
>> during dumping of lambda proxy classes. There's a workaround in
>> `LambdaProxyClassArchive.find`, it won't call
On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad wrote:
>> Before this change, the setting of the
>> `jdk.internal.lambda.disableEagerInitialization` property was not captured
>> during dumping of lambda proxy classes. There's a workaround in
>> `LambdaProxyClassArchive.find`, it won't call
Before this change, the setting of the
`jdk.internal.lambda.disableEagerInitialization` property was not captured
during dumping of lambda proxy classes. There's a workaround in
`LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above
property is set.
This change adds
On Fri, 25 Sep 2020 17:52:24 GMT, Calvin Cheung wrote:
> Following up on archiving lambda proxy classes in dynamic CDS archive
> ([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE
> adds the functionality of archiving of
> lambda proxy classes in static
On Mon, 19 Oct 2020 16:56:19 GMT, Ioi Lam wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> store symbolic name of ref kind (e.g. REF_invokeStatic) in classlist
>
> LGTM
@ik
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request incrementally with
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request incrementally wit
On Fri, 16 Oct 2020 21:25:04 GMT, Mandy Chung wrote:
>> `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invokeStatic
>> LambHello lambda$main$0 ()V ()V`
>> means
>> `@lambda-proxy
>>
>> `
>> It is a symbolic representation of a invoke dynamic constant pool entry.
>>
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request incrementally
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request with a new targe
On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote:
>> Hi, Please review the simple change.
>>
>> The removing of white spaces from end of line in ClassListParser should be
>> moved to before we add lambda-form-invoker
>> line to array. After made such arrangement, changed CDS.java for
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request incrementally with
On Tue, 13 Oct 2020 23:59:38 GMT, Ioi Lam wrote:
>> Calvin Cheung has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now
>> contains ten commits:
>> - fix minimal vm build issues
>> - Merge branch 'master' i
On Wed, 14 Oct 2020 01:44:05 GMT, Mandy Chung wrote:
>> Changes requested by iklam (Reviewer).
>
>> `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello
>> lambda$main$0 ()V ()V`
>
> Can you explain the format?
`@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V
===
> 2226266109 2064768307 (-161497801) -374.848 350.126
> (-24.722)
> instr delta = -161497801-7.2542%
> time delta = -24.722 ms -6.5951%
Calvin Cheung has updated the pull request with a new tar
Following up on archiving lambda proxy classes in dynamic CDS archive
([JDK-8198698](https://bugs.openjdk.java.net/browse/JDK-8198698)), this RFE
adds the functionality of archiving of
lambda proxy classes in static CDS archive.
When the -XX:DumpLoadedClassList is enabled, the constant pool
On Tue, 22 Sep 2020 18:06:40 GMT, Yumin Qi wrote:
> In patch for jdk-8253208, a comma missed after copyright year in
> src/java.base/share/classes/jdk/internal/math/FDBigInteger.java. Also changed
> "@return" to "Returns" in the comment for
> CDS.getRandomSeedForDumping to keep consistent with
Hi Yumin,
I reviewed mostly the native code. Below are my comments:
1) classListParser.hpp
71 bool _lambda_format;
The above name is too generic. How about _lambda_form or _is_lambda_form?
If you rename the above, please also rename the function which returns
the above bool.
Hi Mandy,
Thanks for taking another look.
On 6/3/20 2:07 PM, Mandy Chung wrote:
On 6/3/20 12:34 PM, Calvin Cheung wrote:
I saw David has commented on this. So I'll leave the assert as before
and I've added another assert (see line 1691):
1687 // The following ensures that the caller's
archive. The dynamic archive may initially contain the classes required
by javac to compile a java program, like a HelloWorld. I think this
should be explored as a separate RFE.
I can get some perf numbers on running javac on HelloWorld later.
On 5/29/20 2:29 PM, Calvin Cheung wrote:
RFE: https
RFE: https://bugs.openjdk.java.net/browse/JDK-8198698
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8198698/webrev.00/
There's a high level design doc in the attachment[1] of the RFE.
Passed tiers 1 - 4 tests (including the new tests).
thanks,
Calvin
[1]
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
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
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
k you can use
this in your patch instead of adding loader_type() back.
I'll make the change and do more testing before push.
thanks,
Calvin
No need for new webrev.
Thanks
- Ioi
On 3/5/20 11:48 AM, Calvin Cheung wrote:
On 3/5/20 9:17 AM, Ioi Lam wrote:
Hi Calvin,
Looks good overall. I just hav
e change for JDK-8240244. I've added it back as shared_loader_type().
updated webrev:
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.04/
thanks,
Calvin
Thanks
- Ioi
On 3/4/20 9:13 PM, Calvin Cheung wrote:
Hi David, Ioi,
Here's an updated webrev which doesn't
:12 pm, Calvin Cheung wrote:
Hi David,
On 2/27/20 5:40 PM, David Holmes wrote:
Hi Calvin, Ioi,
Looking good - comments below.
A meta-question: normal application classes are rarely loaded but
not linked so I'm a little surprised this is an issue. What is the
main source of such classes
x = new Child2();
return x.get();
}
}
The following updated webrev includes the above changes in the test case:
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.02/
thanks,
Calvin
Thanks
- Ioi
On 2/27/20 4:48 PM, Calvin Cheung wrote:
Hi David, Ioi,
Thanks for your
forms? Also why
do we need to link them when loading from the archive if they were
never linked when the application actually executed ??
I saw that Ioi already answered the above.
I'll try to answer your questions inline below..
On 28/02/2020 10:48 am, Calvin Cheung wrote:
Hi David, Ioi
Hi David, Ioi,
Thanks for your review and suggestions.
On 2/26/20 9:46 PM, Ioi Lam wrote:
On 2/26/20 7:50 PM, David Holmes wrote:
Hi Calvin,
Adding core-libs-dev as you are messing with their code :)
On 27/02/2020 1:19 pm, Calvin Cheung wrote:
JBS: https://bugs.openjdk.java.net/browse
Hi Christoph,
The changes look good.
I agree that other mentioned items (the JPLIS agent usage and moving the
canonicalize function into hotspot) could be done in separate RFEs.
thanks,
Calvin
On 10/23/19 5:57 AM, Langer, Christoph wrote:
Hi,
I've picked up Ralf's patch and cleaned it up
Thanks, Ioi.
Calvin
On 9/13/18, 4:06 PM, Ioi Lam wrote:
Looks good. Thanks!
Ioi
On Sep 10, 2018, at 11:42 AM, Calvin Cheung wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8190737
webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
Please review this change for handling
that would be a separate and big rfes.
nit:
130 fname, /* Ascii char path name */
the comment probably should be "path name in mb char", or ANSI charset.
Thanks,
-Sherman
On 9/12/18, 4:16 PM, Calvin Cheung wrote:
Hi Sherman,
Thanks for your review.
Please re
Hi Sherman,
Thanks for your review.
Please refer to my reply below...
On 9/10/18, 5:05 PM, Xueming Shen wrote:
On 9/10/18, 11:42 AM, Calvin Cheung wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8190737
webrev: http://cr.openjdk.java.net/~ccheung/8190737/webrev.00/
Please review
Hi Jiangli,
Thanks for this start-up improvement. The changes look good overall.
I've the following minor comments.
1) make/hotspot/symbols/symbols-unix
134 JVM_InitializeFromArchive
If you want the symbols to be in alphabetical order, the above
should be moved after
Hi Vladimir,
Fix looks good to me.
Could you break up lines #3386 (104 chars) and #3391 (146 chars)?
No need to send another webrev for the above change.
thanks,
Calvin
On 11/28/17, 3:51 PM, Vladimir Kozlov wrote:
http://cr.openjdk.java.net/~kvn/8191788/webrev.00/
On 9/8/16, 10:12 AM, Lois Foltan wrote:
On 9/8/2016 9:23 AM, harold seigel wrote:
Hi,
Please review this fix for JDK-8165634. The fix changes the
--add-modules option from being a 'last one wins' option to a
cumulative one. With this change, if multiple --add-modules options
are
68 matches
Mail list logo
