Re: Possible subtle memory model error in ClassValue
On 8/16/20 7:35 PM, Andrew Haley wrote: On 15/08/2020 10:13, Peter Levart wrote: https://github.com/openjdk/jdk/pull/9 Sorry for abusing GitHub pull request mechanism but I don't have bandwidth currently to clone the mercurial repository ;-) That's a lot of work to avoid a simple fence. Two fences, mind you (the read fence is no-op only on Intel). So take half of that work for each fence ;-) Still a lot? No, really it was not much work to make the patch. The real work is yet to come - checking that it is correct. I leaned on the assumption that it is already correct when the cacheArray has to be swapped with bigger array. All accesses to the cacheArray field but the fast-path read-only probing is done under lock. So it is not that hard to reason about most of the code changes. The only changes that are done to code that accesses cacheArray field without holding a lock are two additional null checks in: loadFromCache and probeBackupLocations which basically just make the methods return null (not found) when parameter cache (read from cacheArray field) is found to be null. Now that the set of valid values for cache parameter contains null, there's no need for EMPTY_CACHE. I think that ClassValue was designed to cope with only one pair of fences (the ones that are used for initializing/accessing the final Entry.value field) and that all other accesses are performed with data races. So adding fences to accesses of cacheArray field would mean giving up on the design (John?). Regards, Peter
Re: RFR: JDK-8250611: Cannot display splash screen on Windows
Looks good. - Alexey On 8/14/2020 10:05 AM, Andy Herrick wrote: Please review revised webrev [3] that does not check for client jvm are (always use server) /Andy [3] - http://cr.openjdk.java.net/~herrick/8250611/webrev.02 On 8/13/2020 6:03 PM, Philip Race wrote: Do I understand correctly that you are checking if the client VM is being specified ? I didn't think we had client VMs any more .. -phil. On 8/13/20, 12:35 PM, Andy Herrick wrote: Please review this jpackage fix for issue [1] at [2]. In order to show splash screen from statically linked applauncher, we need to load the dependent libraries of splashscreen.dll first /Andy [1] - https://bugs.openjdk.java.net/browse/JDK-8250611 [2] - http://cr.openjdk.java.net/~herrick/8250611/webrev.01/
RFR: JDK-8249691: jdk/lambda/vm/StrictfpDefault.java file can be removed
Hi all, This is a small fix that helps with some test cleanup. One redundant test file has been removed. Webrev found at: http://cr.openjdk.java.net/~kravikumar/8249691/webrev/ Link to JBS issue: https://bugs.openjdk.java.net/browse/JDK-8249691 Any follow up questions are welcomed. Thanks, Evan
Re: RFR(L) 8244778 Archive full module graph in CDS
On 8/12/20 3:06 PM, Ioi Lam wrote: Hi Lois, Thanks for the comments. I have an updated webrev http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02/ http://cr.openjdk.java.net/~iklam/jdk16/8244778-archive-full-module-graph.v02.delta/ This is very good work. I reviewed the Java code change that looks okay to me. This version is cleaner. I skimmed through the VM code which is a huge change. I see Coleen and Lois reviewing and nothing to add. Mandy
Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
Hi, Ioi
Thanks for review/suggestion. I have updated the webrev at the following link:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/
Following changes done in this patch:
1) move regenerating holder classes into new added file:
lambdaFormInvokers.[ch]pp
"@lambda-form-invoker" tag only observed at jvm side.
2) remove InvokerBytecodeGeneratorHelper.java, move related functions to
existing class, GenerateJLIClassesHelper.java
3) add tracing for SPECIES_RESOLVE, so archive more classes.
4) remove InvokerGenerateBytesException.java, using RuntimeException instead.
5) Changed make file to exclude the new added lamdaFormInvokers.cpp from the
non-cds building list.
6) There is a bug in previous patch, jobject (typeArrayOop) should not be
used directly for loading class since GC will move the java object. Fixed by
copying the bytes from handle to C heap.
7) Tested with tier1,2
Thanks
Yumin
On 8/15/20 6:27 PM, Ioi Lam wrote:
On 8/15/20 6:19 PM, Ioi Lam wrote:
To better capture what we're trying to do in this RFE, I've changed the RFE
title (and the subject of this email thread) to
https://bugs.openjdk.java.net/browse/JDK-8247536
Support for pre-generated java.lang.invoke classes in CDS static archive
I also update the RFE Description to give an overview of the problem and the
solution.
The design document is also updated to reflect Yumin's latest implementation
Oops, sent too quickly. The design doc's title is also updated:
https://wiki.openjdk.java.net/display/HotSpot/Support+for+pre-generated+java.lang.invoke+classes+in+CDS+archive
Thanks
- Ioi
On 8/12/20 11:54 AM, calvin.che...@oracle.com wrote:
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.
2) jvm.cpp
3850 JVM_ENTRY(void, JVM_CDSTraceResolve(JNIEnv* env, jclass ignore, jstring
line))
ignore -> ignored
3) jvm.hpp
210 JVM_CDSTraceResolve(JNIEnv* env, jclass ignore, jstring line);
Same comment as for jvm.cpp
4) metaspaceShared.cpp
2017 size_t i = 0;
2018 while (i < size) {
2019 full_name[i++] = *start++;
2020 }
Could the above be simplified to the following?
strncpy(full_name, start, size - 1);
2029 char* class_name = get_full_class_name(path_name);
Should os::free(class_name) be called before the function returns?
1870 static GrowableArray* lambda_list = NULL;
The name lambda_list is a bit generic, how about lambda_form_list?
2112 lambda_list->append(parser.current_line());
Since parser.current_line() does a strdup, do those buffer need to be freed
after its use? (i.e. after the call to regenerate_holder_classes()?)
In MetaspaceShared::regenerate_holder_classes, before calling up to java, I think it's
better to strip the prefix "@lambda-form-invoker" from the strings. So that the
java InvokerBytecodeGeneratorHelper.readTraceConfig method doesn't need to handle it:
143 case "[LF_RESOLVE]":
144 case InvokerBytecodeGenerator.CDS_LOG_PREFIX:
5) DumpSymbolAndStringTable.java
37 private static final String my_string = "DumpSymbolAndStringTable";
Unused variable?
thanks,
Calvin
On 8/11/20 10:36 AM, Yumin Qi wrote:
Forget to send to @core-lib-dev, the patch changed jdk code.
Thanks
Yumin
Forwarded Message
Subject: RFR: 8247536: Support pre-generated MethodHandle lambda forms in
CDS
Date: Tue, 11 Aug 2020 07:44:34 -0700
From: Yumin Qi
To: hotspot-runtime-...@openjdk.java.net
Hi, Please reivew
bug: https://bugs.openjdk.java.net/browse/JDK-8247536
Webrev: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-01/
Summary: CDS does not archive pre-generated lambda form classes for method
handles:
[0.142s][info][class,load] java.lang.invoke.LambdaForm$MH/0x000800066c40
source: __JVM_LookupDefineClass__
The method handle resolution if not found in the holder class, a class with the
method will be generated and loaded as vm internal created class and not
archived like above. Those class names are mangled as combination of the class
name and the class instance address.
In this patch, collect those method holder class names and their associated methods' signatures when user specify DumpLoadedClassList, and record them in the log file in a format similar to the output format from traced by -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true, but here use another name for CDS: -Djava.lang.invoke.MethodHandle.CDS_TRACE_RESOLVE=true instead. The line prefix also changed from "[LF_RESOLVE]" to "@lambda-invoke-handle". At dump time, regenerate the holder class with those methods and replace the existing holder class and archived it. At runtime, the resolution of the holder class which contains those methods are lo
RFR: JDK-8246804: Incorrect copyright header in TypeAnnotationParser.java
Please review this very simple fix for [1] at [2]. The fix is a very simple one liner change, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246804 [2] http://cr.openjdk.java.net/~vromero/8246804/webrev.00/
Re: RFR: JDK-8246804: Incorrect copyright header in TypeAnnotationParser.java
+1 -Joe On 8/17/2020 1:01 PM, Vicente Romero wrote: Please review this very simple fix for [1] at [2]. The fix is a very simple one liner change, Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8246804 [2] http://cr.openjdk.java.net/~vromero/8246804/webrev.00/
Re: RFR: JDK-8246804: Incorrect copyright header in TypeAnnotationParser.java
+1 Paul. > On Aug 17, 2020, at 1:01 PM, Vicente Romero wrote: > > Please review this very simple fix for [1] at [2]. The fix is a very simple > one liner change, > > Thanks, > Vicente > > [1] https://bugs.openjdk.java.net/browse/JDK-8246804 > [2] http://cr.openjdk.java.net/~vromero/8246804/webrev.00/
Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException
Hi Joe, It turned out that the previous fix did not address plural format cases. That means that just making the divisor negative to indicate non-placeholder cannot distinguish multiple plural cases with the same divisor. Instead, I created a list of placeholders (minimum digits) for each index and count. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ I added a new test case (COMPACT_PATTERN14), which actually is extracted from CLDR 38 Somali locale that demonstrates the issue. I'd appreciate your further review. Naoto On 8/14/20 6:21 PM, Joe Wang wrote: Hi Naoto, Looks good to me. While a negative divisor representing no zeros is newly introduced, the "divisor > 0" checks seem to have always been beneficial. I had to count the number of ""s in COMPACT_PATTERN13 :-) Have a great weekend! Joe On 8/14/2020 3:20 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8251499 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ The current implementation of CompactNumberFormat assumes that there is always the number placeholder part in compact patterns. This is not always true. In fact, upcoming CLDR 38 resurrects such patterns, so this fix is a precursor to support CLDR 38. Naoto
Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
Not a full review of fresh changes. But couple of comments:
* src/hotspot/share/memory/lambdaFormInvokers.cpp and
src/hotspot/share/memory/lambdaFormInvokers.hpp miss "Classpath
exception" clause in the copyright header
* I had suggested a change GenerateJLIClassesPlugin.java in last round
of review. That's still applicable.
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068160.html
-Sundar
On 18/08/20 1:07 am, Yumin Qi wrote:
Hi, Ioi
Thanks for review/suggestion. I have updated the webrev at the
following link:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/
Following changes done in this patch:
1) move regenerating holder classes into new added file:
lambdaFormInvokers.[ch]pp
"@lambda-form-invoker" tag only observed at jvm side.
2) remove InvokerBytecodeGeneratorHelper.java, move related
functions to existing class, GenerateJLIClassesHelper.java
3) add tracing for SPECIES_RESOLVE, so archive more classes.
4) remove InvokerGenerateBytesException.java, using RuntimeException
instead.
5) Changed make file to exclude the new added lamdaFormInvokers.cpp
from the non-cds building list.
6) There is a bug in previous patch, jobject (typeArrayOop) should
not be used directly for loading class since GC will move the java
object. Fixed by copying the bytes from handle to C heap.
7) Tested with tier1,2
Thanks
Yumin
On 8/15/20 6:27 PM, Ioi Lam wrote:
On 8/15/20 6:19 PM, Ioi Lam wrote:
To better capture what we're trying to do in this RFE, I've changed
the RFE title (and the subject of this email thread) to
https://bugs.openjdk.java.net/browse/JDK-8247536
Support for pre-generated java.lang.invoke classes in CDS static
archive
I also update the RFE Description to give an overview of the problem
and the solution.
The design document is also updated to reflect Yumin's latest
implementation
Oops, sent too quickly. The design doc's title is also updated:
https://wiki.openjdk.java.net/display/HotSpot/Support+for+pre-generated+java.lang.invoke+classes+in+CDS+archive
Thanks
- Ioi
On 8/12/20 11:54 AM, calvin.che...@oracle.com wrote:
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.
2) jvm.cpp
3850 JVM_ENTRY(void, JVM_CDSTraceResolve(JNIEnv* env, jclass
ignore, jstring line))
ignore -> ignored
3) jvm.hpp
210 JVM_CDSTraceResolve(JNIEnv* env, jclass ignore, jstring line);
Same comment as for jvm.cpp
4) metaspaceShared.cpp
2017 size_t i = 0;
2018 while (i < size) {
2019 full_name[i++] = *start++;
2020 }
Could the above be simplified to the following?
strncpy(full_name, start, size - 1);
2029 char* class_name = get_full_class_name(path_name);
Should os::free(class_name) be called before the function returns?
1870 static GrowableArray* lambda_list = NULL;
The name lambda_list is a bit generic, how about lambda_form_list?
2112 lambda_list->append(parser.current_line());
Since parser.current_line() does a strdup, do those buffer need to
be freed after its use? (i.e. after the call to
regenerate_holder_classes()?)
In MetaspaceShared::regenerate_holder_classes, before calling up to
java, I think it's better to strip the prefix
"@lambda-form-invoker" from the strings. So that the java
InvokerBytecodeGeneratorHelper.readTraceConfig method doesn't need
to handle it:
143 case "[LF_RESOLVE]":
144 case InvokerBytecodeGenerator.CDS_LOG_PREFIX:
5) DumpSymbolAndStringTable.java
37 private static final String my_string =
"DumpSymbolAndStringTable";
Unused variable?
thanks,
Calvin
On 8/11/20 10:36 AM, Yumin Qi wrote:
Forget to send to @core-lib-dev, the patch changed jdk code.
Thanks
Yumin
Forwarded Message
Subject: RFR: 8247536: Support pre-generated MethodHandle
lambda forms in CDS
Date: Tue, 11 Aug 2020 07:44:34 -0700
From: Yumin Qi
To: hotspot-runtime-...@openjdk.java.net
Hi, Please reivew
bug: https://bugs.openjdk.java.net/browse/JDK-8247536
Webrev: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-01/
Summary: CDS does not archive pre-generated lambda form classes
for method handles:
[0.142s][info][class,load]
java.lang.invoke.LambdaForm$MH/0x000800066c40 source:
__JVM_LookupDefineClass__
The method handle resolution if not found in the holder class, a
class with the method will be generated and loaded as vm internal
created class and not archived like above. Those class names are
mangled as combination of the class name and the class instance
address.
In this patch, collect those method holder class names and their
associated methods' signatures when user specify
DumpLoadedClassList, and record them in t
Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
Hi Sundar,
On 18/08/2020 12:25 pm, sundararajan.athijegannat...@oracle.com wrote:
Not a full review of fresh changes. But couple of comments:
* src/hotspot/share/memory/lambdaFormInvokers.cpp and
src/hotspot/share/memory/lambdaFormInvokers.hpp miss "Classpath
exception" clause in the copyright header
Hotspot files do not use the Classpath exception. That is for .java
sources that will be"linked against" by applications.
Cheers,
David
* I had suggested a change GenerateJLIClassesPlugin.java in last round
of review. That's still applicable.
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068160.html
-Sundar
On 18/08/20 1:07 am, Yumin Qi wrote:
Hi, Ioi
Thanks for review/suggestion. I have updated the webrev at the
following link:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/
Following changes done in this patch:
1) move regenerating holder classes into new added file:
lambdaFormInvokers.[ch]pp
"@lambda-form-invoker" tag only observed at jvm side.
2) remove InvokerBytecodeGeneratorHelper.java, move related
functions to existing class, GenerateJLIClassesHelper.java
3) add tracing for SPECIES_RESOLVE, so archive more classes.
4) remove InvokerGenerateBytesException.java, using RuntimeException
instead.
5) Changed make file to exclude the new added lamdaFormInvokers.cpp
from the non-cds building list.
6) There is a bug in previous patch, jobject (typeArrayOop) should
not be used directly for loading class since GC will move the java
object. Fixed by copying the bytes from handle to C heap.
7) Tested with tier1,2
Thanks
Yumin
On 8/15/20 6:27 PM, Ioi Lam wrote:
On 8/15/20 6:19 PM, Ioi Lam wrote:
To better capture what we're trying to do in this RFE, I've changed
the RFE title (and the subject of this email thread) to
https://bugs.openjdk.java.net/browse/JDK-8247536
Support for pre-generated java.lang.invoke classes in CDS static
archive
I also update the RFE Description to give an overview of the problem
and the solution.
The design document is also updated to reflect Yumin's latest
implementation
Oops, sent too quickly. The design doc's title is also updated:
https://wiki.openjdk.java.net/display/HotSpot/Support+for+pre-generated+java.lang.invoke+classes+in+CDS+archive
Thanks
- Ioi
On 8/12/20 11:54 AM, calvin.che...@oracle.com wrote:
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.
2) jvm.cpp
3850 JVM_ENTRY(void, JVM_CDSTraceResolve(JNIEnv* env, jclass
ignore, jstring line))
ignore -> ignored
3) jvm.hpp
210 JVM_CDSTraceResolve(JNIEnv* env, jclass ignore, jstring line);
Same comment as for jvm.cpp
4) metaspaceShared.cpp
2017 size_t i = 0;
2018 while (i < size) {
2019 full_name[i++] = *start++;
2020 }
Could the above be simplified to the following?
strncpy(full_name, start, size - 1);
2029 char* class_name = get_full_class_name(path_name);
Should os::free(class_name) be called before the function returns?
1870 static GrowableArray* lambda_list = NULL;
The name lambda_list is a bit generic, how about lambda_form_list?
2112 lambda_list->append(parser.current_line());
Since parser.current_line() does a strdup, do those buffer need to
be freed after its use? (i.e. after the call to
regenerate_holder_classes()?)
In MetaspaceShared::regenerate_holder_classes, before calling up to
java, I think it's better to strip the prefix
"@lambda-form-invoker" from the strings. So that the java
InvokerBytecodeGeneratorHelper.readTraceConfig method doesn't need
to handle it:
143 case "[LF_RESOLVE]":
144 case InvokerBytecodeGenerator.CDS_LOG_PREFIX:
5) DumpSymbolAndStringTable.java
37 private static final String my_string =
"DumpSymbolAndStringTable";
Unused variable?
thanks,
Calvin
On 8/11/20 10:36 AM, Yumin Qi wrote:
Forget to send to @core-lib-dev, the patch changed jdk code.
Thanks
Yumin
Forwarded Message
Subject: RFR: 8247536: Support pre-generated MethodHandle
lambda forms in CDS
Date: Tue, 11 Aug 2020 07:44:34 -0700
From: Yumin Qi
To: hotspot-runtime-...@openjdk.java.net
Hi, Please reivew
bug: https://bugs.openjdk.java.net/browse/JDK-8247536
Webrev: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-01/
Summary: CDS does not archive pre-generated lambda form classes
for method handles:
[0.142s][info][class,load]
java.lang.invoke.LambdaForm$MH/0x000800066c40 source:
__JVM_LookupDefineClass__
The method handle resolution if not found in the holder class, a
class with the method will be generated and loaded as vm internal
created class and not archived like above. Those class names are
mangle
Re: RFR: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
Hi David.
Thanks.
-Sundar
On 18/08/20 8:04 am, David Holmes wrote:
Hi Sundar,
On 18/08/2020 12:25 pm, sundararajan.athijegannat...@oracle.com wrote:
Not a full review of fresh changes. But couple of comments:
* src/hotspot/share/memory/lambdaFormInvokers.cpp and
src/hotspot/share/memory/lambdaFormInvokers.hpp miss "Classpath
exception" clause in the copyright header
Hotspot files do not use the Classpath exception. That is for .java
sources that will be"linked against" by applications.
Cheers,
David
* I had suggested a change GenerateJLIClassesPlugin.java in last
round of review. That's still applicable.
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068160.html
-Sundar
On 18/08/20 1:07 am, Yumin Qi wrote:
Hi, Ioi
Thanks for review/suggestion. I have updated the webrev at the
following link:
http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-02/
Following changes done in this patch:
1) move regenerating holder classes into new added file:
lambdaFormInvokers.[ch]pp
"@lambda-form-invoker" tag only observed at jvm side.
2) remove InvokerBytecodeGeneratorHelper.java, move related
functions to existing class, GenerateJLIClassesHelper.java
3) add tracing for SPECIES_RESOLVE, so archive more classes.
4) remove InvokerGenerateBytesException.java, using
RuntimeException instead.
5) Changed make file to exclude the new added
lamdaFormInvokers.cpp from the non-cds building list.
6) There is a bug in previous patch, jobject (typeArrayOop) should
not be used directly for loading class since GC will move the java
object. Fixed by copying the bytes from handle to C heap.
7) Tested with tier1,2
Thanks
Yumin
On 8/15/20 6:27 PM, Ioi Lam wrote:
On 8/15/20 6:19 PM, Ioi Lam wrote:
To better capture what we're trying to do in this RFE, I've
changed the RFE title (and the subject of this email thread) to
https://bugs.openjdk.java.net/browse/JDK-8247536
Support for pre-generated java.lang.invoke classes in CDS static
archive
I also update the RFE Description to give an overview of the
problem and the solution.
The design document is also updated to reflect Yumin's latest
implementation
Oops, sent too quickly. The design doc's title is also updated:
https://wiki.openjdk.java.net/display/HotSpot/Support+for+pre-generated+java.lang.invoke+classes+in+CDS+archive
Thanks
- Ioi
On 8/12/20 11:54 AM, calvin.che...@oracle.com wrote:
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.
2) jvm.cpp
3850 JVM_ENTRY(void, JVM_CDSTraceResolve(JNIEnv* env, jclass
ignore, jstring line))
ignore -> ignored
3) jvm.hpp
210 JVM_CDSTraceResolve(JNIEnv* env, jclass ignore, jstring line);
Same comment as for jvm.cpp
4) metaspaceShared.cpp
2017 size_t i = 0;
2018 while (i < size) {
2019 full_name[i++] = *start++;
2020 }
Could the above be simplified to the following?
strncpy(full_name, start, size - 1);
2029 char* class_name = get_full_class_name(path_name);
Should os::free(class_name) be called before the function returns?
1870 static GrowableArray* lambda_list = NULL;
The name lambda_list is a bit generic, how about lambda_form_list?
2112 lambda_list->append(parser.current_line());
Since parser.current_line() does a strdup, do those buffer need
to be freed after its use? (i.e. after the call to
regenerate_holder_classes()?)
In MetaspaceShared::regenerate_holder_classes, before calling up
to java, I think it's better to strip the prefix
"@lambda-form-invoker" from the strings. So that the java
InvokerBytecodeGeneratorHelper.readTraceConfig method doesn't
need to handle it:
143 case "[LF_RESOLVE]":
144 case
InvokerBytecodeGenerator.CDS_LOG_PREFIX:
5) DumpSymbolAndStringTable.java
37 private static final String my_string =
"DumpSymbolAndStringTable";
Unused variable?
thanks,
Calvin
On 8/11/20 10:36 AM, Yumin Qi wrote:
Forget to send to @core-lib-dev, the patch changed jdk code.
Thanks
Yumin
Forwarded Message
Subject: RFR: 8247536: Support pre-generated MethodHandle
lambda forms in CDS
Date: Tue, 11 Aug 2020 07:44:34 -0700
From: Yumin Qi
To: hotspot-runtime-...@openjdk.java.net
Hi, Please reivew
bug: https://bugs.openjdk.java.net/browse/JDK-8247536
Webrev: http://cr.openjdk.java.net/~minqi/2020/8247536/webrev-01/
Summary: CDS does not archive pre-generated lambda form
classes for method handles:
[0.142s][info][class,load]
java.lang.invoke.LambdaForm$MH/0x000800066c40 source:
__JVM_LookupDefineClass__
The method handle resolution if not found in the holder class, a
class with the method will be generated and loaded as vm
internal creat
Re: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException
Hi Naoto, Looks good overall. One nit, blocks 1633-1639 and 1642-1649 may share a common private method with a parameter that takes either matchedPosIndex or matchedNegIndex, if you want. Best, Joe On 8/17/20 4:42 PM, naoto.s...@oracle.com wrote: Hi Joe, It turned out that the previous fix did not address plural format cases. That means that just making the divisor negative to indicate non-placeholder cannot distinguish multiple plural cases with the same divisor. Instead, I created a list of placeholders (minimum digits) for each index and count. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ I added a new test case (COMPACT_PATTERN14), which actually is extracted from CLDR 38 Somali locale that demonstrates the issue. I'd appreciate your further review. Naoto On 8/14/20 6:21 PM, Joe Wang wrote: Hi Naoto, Looks good to me. While a negative divisor representing no zeros is newly introduced, the "divisor > 0" checks seem to have always been beneficial. I had to count the number of ""s in COMPACT_PATTERN13 :-) Have a great weekend! Joe On 8/14/2020 3:20 PM, naoto.s...@oracle.com wrote: Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8251499 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ The current implementation of CompactNumberFormat assumes that there is always the number placeholder part in compact patterns. This is not always true. In fact, upcoming CLDR 38 resurrects such patterns, so this fix is a precursor to support CLDR 38. Naoto
