Hi Ioi,
On 3/5/20 9:16 PM, Ioi Lam wrote:
Hi Calvin,
Looks good.
Thanks for taking another look.
In JDK-8240244, I removed "ik->loader_type() != 0" because it's
unclear what it means. I replaced with a new method
InstanceKlass::is_shared_unregistered_class(). I think you can use
this in y
Hi Calvin,
Looks good.
In JDK-8240244, I removed "ik->loader_type() != 0" because it's unclear
what it means. I replaced with a new method
InstanceKlass::is_shared_unregistered_class(). I think you can use this
in your patch instead of adding loader_type() back.
No need for new webrev.
Tha
On 3/5/20 9:17 AM, Ioi Lam wrote:
Hi Calvin,
Looks good overall. I just have two comment:
I think this is not needed:
306 void ConstantPool::resolve_class_constants(TRAPS) {
307 Arguments::assert_is_dumping_archive();
I've reverted this change.
because this function is used to resolve
Hi Calvin,
Looks good overall. I just have two comment:
I think this is not needed:
306 void ConstantPool::resolve_class_constants(TRAPS) {
307 Arguments::assert_is_dumping_archive();
because this function is used to resolve all Strings in the statically
dumped classes to archive all the
On 5/03/2020 3:13 pm, Calvin Cheung wrote:
Hi David, Ioi,
Here's an updated webrev which doesn't involve changing
InstanceKlass::verify_on() and made use of the changes for JDK-8240481.
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/
No further comments from me. Thanks for
Hi David, Ioi,
Here's an updated webrev which doesn't involve changing
InstanceKlass::verify_on() and made use of the changes for JDK-8240481.
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.03/
thanks,
Calvin
On 3/1/20 10:14 PM, David Holmes wrote:
Hi Calvin,
On 28/02/2020 4:
Hi Calvin,
On 28/02/2020 4: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
On 2/27/20 10:14 PM, Calvin Cheung wrote:
Hi Ioi,
On 2/27/20 8:22 PM, Ioi Lam wrote:
Hi Calvin,
This looks good to me.
Thanks for taking another look.
I would suggest adding the something like this to the test case:
class Child extends Parent {
int get() {return 2;}
int dummy()
Hi Ioi,
On 2/27/20 8:22 PM, Ioi Lam wrote:
Hi Calvin,
This looks good to me.
Thanks for taking another look.
I would suggest adding the something like this to the test case:
class Child extends Parent {
int get() {return 2;}
int dummy() {
// When Child is linked during dynam
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 - generated classes like lambda fo
Hi Ioi,
On 28/02/2020 2:09 pm, Ioi Lam wrote:
Hi David,
There classes are usually loaded during verification. They are not
linked because they are referenced only by methods that were never
executed during dynamic dumping. You can see an example here
http://cr.openjdk.java.net/~ccheung/jdk1
Hi Calvin,
This looks good to me.
I would suggest adding the something like this to the test case:
class Child extends Parent {
int get() {return 2;}
int dummy() {
// When Child is linked during dynamic dump (when the VM is
shutting
// down), it will be verified, which
Hi David,
There classes are usually loaded during verification. They are not
linked because they are referenced only by methods that were never
executed during dynamic dumping. You can see an example here
http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/test/hotspot/jtreg/runtime/c
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 - generated classes like lambda forms? Also why
do we need to link them when loading
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/JDK
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/JDK-8232081
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/
The proposed
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/JDK-8232081
webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8232081/webrev.00/
The proposed changeset for this RFE adds a JVM_LinkClasse
17 matches
Mail list logo
