Re: Feature suggestion: Add static equals methods to Float and Double

[Joseph D. Darcy]

Catching up on email...

On 1/8/2019 10:55 AM, Hans Boehm wrote:

The IEEE standard does say that for quiet NaNs, the value (or one of them)
"should" be preserved by most operations on the quiet NaN. I have not heard
of implementations violating this for anything other than the "quiet" bit.
Thus I don't immediately see why it would be problematic to encode an
explicitly programmer-introduced error cause in the remaining bits (as
opposed to relying on hardware-generated patterns). I have not seen
non-testing code that does so, but I would be mildly surprised if it
doesn't exist somewhere.


The IEEE standard does recommend the "payload" of NaN bits be preserved, 
that is the significand bits of the NaN. The various versions of 754 and 
its draft revision are less committal about the sign bit of a NaN. Some 
processors use an implementation of, say, floating-point multiply where 
the sign bit of the product is the XOR of the sign bit of the inputs. In 
interests of keeping such calculations more straightforward, an is-NaN 
check is not included on this pathway. That is all well and good in 
terms of supporting the "retrospective diagnostics" intention of NaN 
payloads, but does run afoul of aspirations to have a predictable sign 
bit exposed via a raw-bits view.


Cheers,

-Joe

Re: High memory usage / leaks was: Best mailing list for JVM embedding

[Bernd Eckenfels]

I don’t think the launcher is doing this, it is the class loader, that’s 
nothing new. You can turn on verbose security debug to see it in all versions.

--
https://Bernd.eckenfels.net


Von: core-libs-dev  im Auftrag von 
Robert Marcano 
Gesendet: Mittwoch, Januar 23, 2019 2:18 AM
An: Alan Bateman
Cc: OpenJDK Dev list; core-libs-dev Libs
Betreff: Re: High memory usage / leaks was: Best mailing list for JVM embedding

On Tue, Jan 22, 2019, 5:53 AM Alan Bateman  On 22/01/2019 4:48 am, Robert Marcano wrote:
> >> :
> >>
> >> So the question now is, why signed jars could affect the memory usage
> >> of an application (we aren't doing JAR verification on our custom
> >> launcher, yet), just by being on the java.class.path? IIRC the
> >> initial application classpath JARs were never verified previously (by
> >> the java launcher alone, without JNLP around).
> >>
> >> Note: Tested with JARs signed with a self signed certificate and with
> >> one signed with a private CA. At most, signing the JARs could slow
> >> down the start up if it is now expected to these being verified by
> >> the java launcher (is it true?) but not higher memory usage and no
> >> reductions after a GC cycle but constants heap size increases.
> Signed JARs can be expensive to verify, esp. on first usage as the
> verification is likely to result in early loading of a lot of security
> classes and infrastructure. If you can narrow down the apparently memory
> leak to a small test case with analysis to suggest it's a JDK bug then
> it would be good to get a bug submitted.
>
> -Alan


Greeting. Sure, I will work on a distributable reproduction of the problem
today but it is new to me that the java launcher do JARs verification now.
If it is doing it I doesn't make sense to me, because a self signed or
unrecognized CA doesn't trigger a validation error.

>

RE: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

[Patrick Zhang]

Appreciate all your kind help in making it happen.

Regards
Patrick

From: Roger Riggs 
Sent: Tuesday, January 22, 2019 10:56 PM
To: David Holmes ; Patrick Zhang 

Cc: core-libs-dev 
Subject: Re: 8215976: OpenJDK fails to build with GCC when the #include 
inside zip.cpp comes from a non-sysroot path

Hi David,

Thanks for running the tests.

Pushed.

Thanks, Roger
On 01/22/2019 01:45 AM, David Holmes wrote:
Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris sparcv9.

David

On 22/01/2019 2:01 pm, David Holmes wrote:

Hi Patrick,

I'm putting this through our test system (again) and will report back when its 
complete.

I also updated the bug report with the patch and assigned to Roger as the 
sponsor.

Cheers,
David

On 22/01/2019 12:21 pm, Patrick Zhang wrote:

Thanks Roger.

I did a try to push the patch within a branch to jdk/submit, and saw 
“Permission denied (publickey)”. I sent my SSH pub key to 
keys(at)openjdk.java.net but got no response. I heard only committers can have 
the access right, could you please help?

Regards

Patrick

*From:* Roger Riggs 
*Sent:* Wednesday, January 16, 2019 11:07 PM
*To:* Alan Bateman ; 
Patrick Zhang 
; David 
Holmes 
*Cc:* core-libs-dev 

*Subject:* Re: 8215976: OpenJDK fails to build with GCC when the 
#include inside zip.cpp comes from a non-sysroot path

Hi,

I can sponsor this. Let me know when the jdk-submit is complete.

Thanks, Roger

On 01/16/2019 10:03 AM, Alan Bateman wrote:

On 16/01/2019 02:30, Patrick Zhang wrote:

Looks .patch didn't work as an attachment, retry with .txt and
paste the text below as well. Sorry for one more message here.

I think this patch looks okay and I assume you'll test it in the
jdk-submit repo to make sure it builds on all platforms.

-Alan

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

[Lance Andersen]

> On Jan 22, 2019, at 12:02 PM, Alan Bateman  wrote:
> 
> On 19/01/2019 12:46, Lance Andersen wrote:
>> Hi all,
>> 
>> Please review the  fix for JDK-8217393 which updates the javadocs for 
>> Attriibutes::equals to clarify its behavior to match its implementation
>> 
>> —
>> hg diff
>> diff -r c5d6b4480c6c 
>> src/java.base/share/classes/java/util/jar/Attributes.java
>> --- a/src/java.base/share/classes/java/util/jar/Attributes.java  Thu Jan 
>> 17 13:46:12 2019 -0800
>> +++ b/src/java.base/share/classes/java/util/jar/Attributes.java  Sat Jan 
>> 19 07:35:55 2019 -0500
>> @@ -265,9 +265,10 @@
>>  }
>>/**
>> - * Compares the specified Attributes object with this Map for equality.
>> - * Returns true if the given object is also an instance of Attributes
>> - * and the two Attributes objects represent the same mappings.
>> + * Compares the specified object with this Map for equality.
>> + * Returns true if the given object is also a Map
>> + * and the two objects represent the same Manifest
>> + * attribute name-value mappings.
>> 
> I think this looks okay although I like Martin's suggestion to just inherit 
> the javadoc as Attributes is a Map.

I had thought about that but felt that keeping the javadoc similar to what it 
has been might be the better approach given it has been around since JDK 1.2

If we were to inherit the javadoc, we should probably look at the rest of the 
methods to see where else it would  make sense to inherit the javadoc 

Best
Lance
> 
> -Alan

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

[Mikael Vidstedt]

Mandy, Igor - thanks! Change pushed to jdk12.

Cheers,
Mikael

> On Jan 22, 2019, at 4:34 PM, Igor Ignatyev  wrote:
> 
> looks good.
> 
> -- Igor
> 
>> On Jan 22, 2019, at 4:30 PM, Mandy Chung  wrote:
>> 
>> +1
>> 
>> Mandy
>> 
>> On 1/22/19 4:26 PM, Mikael Vidstedt wrote:
>>> Please review this change which back ports the problem listing of 
>>> LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to 
>>> push it to jdk12, but that plan got lost somewhere on the way).
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349
>>> Webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/
>>> 
>>> The change is the same as the one in jdk/jdk, but the copyright year was 
>>> already updated in jdk12, so there was a trivially resolved merge conflict.
>>> 
>>> Cheers,
>>> Mikael
>>> 
 On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt  
 wrote:
 
 
 Thanks Igor! Pushed.
 
 Cheers,
 Mikael
 
> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev  
> wrote:
> 
> Mikael,
> 
> looks good and trivial to me.
> 
> -- Igor
> 
>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt 
>>  wrote:
>> 
>> 
>> Please review this change which adds 
>> java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem 
>> list until the main bug has been addressed.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 
>> 
>> Webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/
>>  
>> 
>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 
>> 
>> 
>> Cheers,
>> Mikael
>> 
>> 
> 

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

[Igor Ignatyev]

looks good.

-- Igor

> On Jan 22, 2019, at 4:30 PM, Mandy Chung  wrote:
> 
> +1
> 
> Mandy
> 
> On 1/22/19 4:26 PM, Mikael Vidstedt wrote:
>> Please review this change which back ports the problem listing of 
>> LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to 
>> push it to jdk12, but that plan got lost somewhere on the way).
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349
>> Webrev: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/
>> 
>> The change is the same as the one in jdk/jdk, but the copyright year was 
>> already updated in jdk12, so there was a trivially resolved merge conflict.
>> 
>> Cheers,
>> Mikael
>> 
>>> On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt  
>>> wrote:
>>> 
>>> 
>>> Thanks Igor! Pushed.
>>> 
>>> Cheers,
>>> Mikael
>>> 
 On Jan 17, 2019, at 2:07 PM, Igor Ignatyev  
 wrote:
 
 Mikael,
 
 looks good and trivial to me.
 
 -- Igor
 
> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt  
> wrote:
> 
> 
> Please review this change which adds 
> java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem 
> list until the main bug has been addressed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 
> 
> Webrev: 
> http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ 
> 
> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 
> 
> 
> Cheers,
> Mikael
> 
> 

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

[Mandy Chung]

+1

Mandy

On 1/22/19 4:26 PM, Mikael Vidstedt wrote:

Please review this change which back ports the problem listing of 
LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push 
it to jdk12, but that plan got lost somewhere on the way).

Bug: https://bugs.openjdk.java.net/browse/JDK-8217349
Webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/

The change is the same as the one in jdk/jdk, but the copyright year was 
already updated in jdk12, so there was a trivially resolved merge conflict.

Cheers,
Mikael


On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt  wrote:


Thanks Igor! Pushed.

Cheers,
Mikael


On Jan 17, 2019, at 2:07 PM, Igor Ignatyev  wrote:

Mikael,

looks good and trivial to me.

-- Igor


On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt  wrote:


Please review this change which adds 
java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem list 
until the main bug has been addressed.

Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 

Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ 

Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 


Cheers,
Mikael

Re: RFR(XS): 8217349: Problem list java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java

[Mikael Vidstedt]

Please review this change which back ports the problem listing of 
LFMultiThreadCachingTest.java to jdk12 (my original intent was actually to push 
it to jdk12, but that plan got lost somewhere on the way).

Bug: https://bugs.openjdk.java.net/browse/JDK-8217349
Webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8217349/jdk12/webrev.00/open/webrev/ 


The change is the same as the one in jdk/jdk, but the copyright year was 
already updated in jdk12, so there was a trivially resolved merge conflict.

Cheers,
Mikael

> On Jan 17, 2019, at 3:00 PM, Mikael Vidstedt  
> wrote:
> 
> 
> Thanks Igor! Pushed.
> 
> Cheers,
> Mikael
> 
>> On Jan 17, 2019, at 2:07 PM, Igor Ignatyev  wrote:
>> 
>> Mikael,
>> 
>> looks good and trivial to me.
>> 
>> -- Igor
>> 
>>> On Jan 17, 2019, at 2:02 PM, Mikael Vidstedt  
>>> wrote:
>>> 
>>> 
>>> Please review this change which adds 
>>> java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java to the problem 
>>> list until the main bug has been addressed.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217349 
>>> 
>>> Webrev: 
>>> http://cr.openjdk.java.net/~mikael/webrevs/8217349/webrev.00/open/webrev/ 
>>> 
>>> Main bug: https://bugs.openjdk.java.net/browse/JDK-8151492 
>>> 
>>> 
>>> Cheers,
>>> Mikael
>>> 
>> 
> 

Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

[Mandy Chung]

On 1/22/19 2:25 PM, Roger Riggs wrote:

Hi Mandy,

Updated webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/




Looks good.



Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new 
work for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity 
exception during the VM boot up.




I also want to understand what changes in 13 causes the difference.

I was prototyping some more properties ideas.
I suspect that in the previous init sequence, the Locale had been cached.
A closed test had failed, in part because it had changed the default 
locale

and then installed a security manager.


I see how ConstantDesc gets initialized during initialization of 
VarHandle from
your stack trace.  I can't reproduce it and so I assume it was triggered 
by your
local change.  In any case, converting String.format to string concat is 
fine.


I am sure Claes may look at the startup and class initialization if we 
can avoid

loading VarHandleDesc from clinit.

Mandy

Re: High memory usage / leaks was: Best mailing list for JVM embedding

[Robert Marcano]

On Tue, Jan 22, 2019, 5:53 AM Alan Bateman  On 22/01/2019 4:48 am, Robert Marcano wrote:
> >> :
> >>
> >> So the question now is, why signed jars could affect the memory usage
> >> of an application (we aren't doing JAR verification on our custom
> >> launcher, yet), just by being on the java.class.path? IIRC the
> >> initial application classpath JARs were never verified previously (by
> >> the java launcher alone, without JNLP around).
> >>
> >> Note: Tested with JARs signed with a self signed certificate and with
> >> one signed with a private CA. At most, signing the JARs could slow
> >> down the start up if it is now expected to these being verified by
> >> the java launcher (is it true?) but not higher memory usage and no
> >> reductions after a GC cycle but constants heap size increases.
> Signed JARs can be expensive to verify, esp. on first usage as the
> verification is likely to result in early loading of a lot of security
> classes and infrastructure. If you can narrow down the apparently memory
> leak to a small test case with analysis to suggest it's a JDK bug then
> it would be good to get a bug submitted.
>
> -Alan


Greeting. Sure, I will work on a distributable reproduction of the problem
today but it is new to me that the java launcher do JARs verification now.
If it is doing it I doesn't make sense to me, because a self signed or
unrecognized  CA doesn't trigger a validation error.

>

Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

[Roger Riggs]

Hi Mandy,

Updated webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-2/

On 1/22/19 3:47 PM, Mandy Chung wrote:



On 1/22/19 12:29 PM, Naoto Sato wrote:

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), 
which is the language invariant locale.




Alternatively, convert those String.format to string concatenation and 
they

are pretty simple format only one argument.

ok,



Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new 
work for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity 
exception during the VM boot up.




I also want to understand what changes in 13 causes the difference.

I was prototyping some more properties ideas.
I suspect that in the previous init sequence, the Locale had been cached.
A closed test had failed, in part because it had changed the default locale
and then installed a security manager.


Is there a regression test?


My test class is:
public class Circ {
    public static void main(String[] args) {
    Locale.setDefault(Locale.ENGLISH);
    System.setSecurityManager(new SecurityManager());

    NumberFormat nf = NumberFormat.getInstance();
    }
}

The circularity error only occurred if the default locale was changed.

But I was unable to reproduce it without other changes.

Thanks, Roger


Mandy


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that 
uses String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup 
sequence before

the Locales and providers are initialized.

See the bug report for the full stack trace.
https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work 
for jdk 13.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger

Re: [13] RFR: 8216969: ParseException thrown for certain months with russian locale

[Roger Riggs]

Looks good.

Thanks, Roger


On 1/22/19 3:31 PM, Naoto Sato wrote:

Hi Roger,

Thanks. Modified as suggested:

http://cr.openjdk.java.net/~naoto/8216969/webrev.02/

Naoto

On 1/19/19 10:03 AM, Roger Riggs wrote:

Hi Naoto,

SimpleDateFormat: 2454, perhaps add javadoc about what it is doing 
and why.
   Use only the official style fields and avoid using the 0x8000 that 
is supposed to be internal to Calendar.


2457: (forceStandaloneForm ? Calendar.SHORT_STANDALONE ? 
SHORT_FORMAT) 2460: (forceStandaloneForm ? Calendar.LONG_STANDALONE ? 
LONG_FORMAT)


Thanks, Roger

On 01/18/2019 06:45 PM, naoto.s...@oracle.com wrote:

Gentle reminder. Still waiting for reviews from OpenJDK Reviewers.

Naoto

On 1/18/19 1:57 AM, Nishit Jain wrote:

Looks Good.

Regards,
Nishit Jain
On 17-01-2019 22:07, Naoto Sato wrote:

Hi Nishit,

Thanks. Updated:

http://cr.openjdk.java.net/~naoto/8216969/webrev.01/

Naoto

On 1/17/19 2:57 AM, Nishit Jain wrote:

Hi Naoto,

Looks good to me. Just a small suggestion.

- To improve readability, can we declare "standalone mask" 
(0x8000) as a static field and use that at all the places?


Regards,
Nishit Jain
On 17-01-2019 05:50, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8216969

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8216969/webrev.00/

For parsing the context sensitive month 'M', the logic was to 
look for the best match for the short name regardless of the 
styles. Changed the parsing code to take the context into account.


Naoto

Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString

[Joe Darcy]

Hi Remi,

Catching up on email, at least to my eye, the current version is easier 
to read than the proposed refactoring in both cases.


I wouldn't expect this code to be performance critical so I'm inclined 
to leave the code as-is unless a performance motivation is found.


Thanks for the comments,

-Joe

On 1/16/2019 1:21 AM, Remi Forax wrote:

Hi Joe,
in j.l.Class, in methodToString, can you change
   sb.append(getName() + "." + name + "(");
to
   sb.append(getName()).append(".").append(name).append('(');
because using the concatenation inside a StringBuilder creates another 
StringBuilder (java.lang doesn't use the StringConcatFactory).

also
   return typeVar.getName() + " extends " +
  Arrays.stream(bounds)
.map(Type::getTypeName)
.collect(Collectors.joining(" & "));
can be written
   return Arrays.stream(bounds)
.map(Type::getTypeName)
.collect(Collectors.joining(" & ", typeVar.getName().concat(" extends "), 
""));
which also avoid the creation of an intermediary StringBuilder (at the cost of 
the code being less readable).
(in that case, you have also to change the same code in Executable).

regards,
Rémi

- Mail original -

De: "joe darcy" 
À: "Stuart Marks" 
Cc: "core-libs-dev" 
Envoyé: Mercredi 16 Janvier 2019 04:05:05
Objet: Re: JDK 13 RFR of JDK-8217000: Refactor Class::methodToString
Good catch on the 3-argument joining in this case; I'll push with that
amendment.

Thanks for the review,

-Joe

On 1/15/2019 3:19 PM, Stuart Marks wrote:


On 1/14/19 7:41 PM, Joe Darcy wrote:

PS And for good measure, made analogous changes in Executable.java:

  http://cr.openjdk.java.net/~darcy/8217000.1/

Thanks for following up on this. Overall, looks good. One point:

  114 sb.append('(');
  115
  116 sb.append(Arrays.stream(parameterTypes)
  117   .map(Type::getTypeName)
  118   .collect(Collectors.joining(",")));
  119
  120 sb.append(')');

I think you can use the 3-arg form of joining() here, since the prefix
and suffix are included even if the stream is empty.

s'marks

Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

[Mandy Chung]

On 1/22/19 12:29 PM, Naoto Sato wrote:

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), 
which is the language invariant locale.




Alternatively, convert those String.format to string concatenation and they
are pretty simple format only one argument.


Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new work 
for

> jdk 13.

Is this new code in 13? l10n causes this type of circularity exception 
during the VM boot up.




I also want to understand what changes in 13 causes the difference.

Is there a regression test?

Mandy


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that 
uses String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence 
before

the Locales and providers are initialized.

See the bug report for the full stack trace.
   https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work 
for jdk 13.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger

Re: [13] RFR: 8216969: ParseException thrown for certain months with russian locale

[Naoto Sato]

Hi Roger,

Thanks. Modified as suggested:

http://cr.openjdk.java.net/~naoto/8216969/webrev.02/

Naoto

On 1/19/19 10:03 AM, Roger Riggs wrote:

Hi Naoto,

SimpleDateFormat: 2454, perhaps add javadoc about what it is doing and why.
   Use only the official style fields and avoid using the 0x8000 that is 
supposed to be internal to Calendar.


2457: (forceStandaloneForm ? Calendar.SHORT_STANDALONE ? SHORT_FORMAT) 
2460: (forceStandaloneForm ? Calendar.LONG_STANDALONE ? LONG_FORMAT)


Thanks, Roger

On 01/18/2019 06:45 PM, naoto.s...@oracle.com wrote:

Gentle reminder. Still waiting for reviews from OpenJDK Reviewers.

Naoto

On 1/18/19 1:57 AM, Nishit Jain wrote:

Looks Good.

Regards,
Nishit Jain
On 17-01-2019 22:07, Naoto Sato wrote:

Hi Nishit,

Thanks. Updated:

http://cr.openjdk.java.net/~naoto/8216969/webrev.01/

Naoto

On 1/17/19 2:57 AM, Nishit Jain wrote:

Hi Naoto,

Looks good to me. Just a small suggestion.

- To improve readability, can we declare "standalone mask" (0x8000) 
as a static field and use that at all the places?


Regards,
Nishit Jain
On 17-01-2019 05:50, naoto.s...@oracle.com wrote:

Hi,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8216969

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8216969/webrev.00/

For parsing the context sensitive month 'M', the logic was to look 
for the best match for the short name regardless of the styles. 
Changed the parsing code to take the context into account.


Naoto

Re: RFR 8217339: ClassCircularityError loading NumberFormatProvider

[Naoto Sato]

Hi Roger,

I'd use Locale.ROOT instead of Locale.ENGLISH in String.format(), which 
is the language invariant locale.


Other changes look good.

BTW,

> I have not found a reproducer for jdk 12, it only occurs on new work for
> jdk 13.

Is this new code in 13? l10n causes this type of circularity exception 
during the VM boot up.


Naoto

On 1/22/19 12:08 PM, Roger Riggs wrote:
A ClassCircularityError can occur via the ClassDescriptor code that uses 
String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence 
before

the Locales and providers are initialized.

See the bug report for the full stack trace.
   https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work for 
jdk 13.


Webrev:
  http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger

RFR 8217339: ClassCircularityError loading NumberFormatProvider

[Roger Riggs]

A ClassCircularityError can occur via the ClassDescriptor code that uses 
String.format to

concatenate strings.

Please review a change to use string concatenation or a known locale 
instead

of the default locale in calls to String.format.

The java.lang.constant APIs can be used early in the startup sequence before
the Locales and providers are initialized.

See the bug report for the full stack trace.
  https://bugs.openjdk.java.net/browse/JDK-8217339

I have not found a reproducer for jdk 12, it only occurs on new work for 
jdk 13.


Webrev:
 http://cr.openjdk.java.net/~rriggs/webrev-circ-error-8217339-1

Thanks, Roger

Re: Manifest copy constructor does not deeply copy individual section Attributes

[Roger Riggs]

Hi Phillip,

Did you discover need for a deeper copy?  If so, can you elaborate?
It may be that adding a new constructor would be cleaner.

I'd suggest clarifying the documentation of existing methods as opposed
to changing the spec and implementation and the possible risks
to clients.

Thanks, Roger

On 01/21/2019 05:50 PM, Lance Andersen wrote:

Hi Philipp,

This is going to take some further discussion/input as this has been documented 
for sometime as a shallow copy.

If there is a consensus  to move this forward, it will also require a CSR.   I 
can help with that and sponsoring the updates,  if the decision is to go ahead 
with the proposed change

Best
Lance

On Jan 19, 2019, at 2:34 PM, Philipp Kunz  wrote:

Hi again,
Just after having sent the previous mail I found Manifest::clone
explicitly says it creates a shallow copy which is true only to a
certain extent. It deeply copies main attributes as well as individual
sections map already now and only shallowly copies individual sections
attributes maps.
I don't know about the background of it or why clone should only do a
shallow copy but if clone should really create a shallow copy, it
should probably create an even more shallow copy. In any case I figure
some potential for clarification at least.
Probably mostly because I already began a patch in the previous
message, I continued and attached another patch for a deep copy
approach. There might still be some reason not to deeply copy manifests
which I don't intend to forestall.
Philipp

On Sat, 2019-01-19 at 19:32 +0100, Philipp Kunz wrote:

Hi,

Creating a new manifest as a copy from an existing one using the copy
constructor assigns the new manifest individual sections entries map
the same values which are references to attributes as the original
rather than copying them as well deeply resulting in two manifests
pointing to the same attributes instances modifications to which
always affect both manifests. See test and proposed fix in the
attached patch.

Regards,
Philipp



  
   

  Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: JDK-8217393 Re: Clarification in Attributes equal

[Alan Bateman]

On 19/01/2019 12:46, Lance Andersen wrote:

Hi all,

Please review the  fix for JDK-8217393 which updates the javadocs for 
Attriibutes::equals to clarify its behavior to match its implementation

—
hg diff
diff -r c5d6b4480c6c src/java.base/share/classes/java/util/jar/Attributes.java
--- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Jan 17 
13:46:12 2019 -0800
+++ b/src/java.base/share/classes/java/util/jar/Attributes.java Sat Jan 19 
07:35:55 2019 -0500
@@ -265,9 +265,10 @@
  }
  
  /**

- * Compares the specified Attributes object with this Map for equality.
- * Returns true if the given object is also an instance of Attributes
- * and the two Attributes objects represent the same mappings.
+ * Compares the specified object with this Map for equality.
+ * Returns true if the given object is also a Map
+ * and the two objects represent the same Manifest
+ * attribute name-value mappings.

I think this looks okay although I like Martin's suggestion to just 
inherit the javadoc as Attributes is a Map.


-Alan

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

[Alan Bateman]

On 18/01/2019 14:28, Peter Levart wrote:


...unless you actually want users to construct their own MapMode(s), 
like you mentioned is the case with FileChannel.open() and 
FileAttribute interface. But there this makes sense because the 
backend (FileSystem) is also pluggable, so users can define their own 
FileSystem implementations that consume their own FileAttribute(s)...


Are you proposing to add an spi for MappedByteBuffer's here? That 
would be an overkill for this feature, I think...
No, we definitely don't want to go there as buffers are closed 
abstraction. Instead, this is just about allowing the JDK to support 
additional map modes beyond those specified by FileChannel.map. If you 
create your own MapMode and call the map method with it then it will be 
rejected, probably UOE. With the suggestion, a JDK-specific module would 
define READ_WRITE_SYNC and you could pass that mode to FileChannel.map. 
There's a bit of plumbing needed make that work but there are examples 
of this already (e.g. socket options and file open options).


-Alan.

Re: 8215976: OpenJDK fails to build with GCC when the #include inside zip.cpp comes from a non-sysroot path

[Roger Riggs]

Hi David,

Thanks for running the tests.

Pushed.

Thanks, Roger

On 01/22/2019 01:45 AM, David Holmes wrote:
Mach 5 tier 1 - 3 tests passed on Linux/OS X/Windows x64 and Solaris 
sparcv9.


David

On 22/01/2019 2:01 pm, David Holmes wrote:

Hi Patrick,

I'm putting this through our test system (again) and will report back 
when its complete.


I also updated the bug report with the patch and assigned to Roger as 
the sponsor.


Cheers,
David

On 22/01/2019 12:21 pm, Patrick Zhang wrote:

Thanks Roger.

I did a try to push the patch within a branch to jdk/submit, and saw 
“Permission denied (publickey)”. I sent my SSH pub key to 
keys(at)openjdk.java.net but got no response. I heard only 
committers can have the access right, could you please help?


Regards

Patrick

*From:* Roger Riggs 
*Sent:* Wednesday, January 16, 2019 11:07 PM
*To:* Alan Bateman ; Patrick Zhang 
; David Holmes 


*Cc:* core-libs-dev 
*Subject:* Re: 8215976: OpenJDK fails to build with GCC when the 
#include inside zip.cpp comes from a non-sysroot path


Hi,

I can sponsor this. Let me know when the jdk-submit is complete.

Thanks, Roger

On 01/16/2019 10:03 AM, Alan Bateman wrote:

    On 16/01/2019 02:30, Patrick Zhang wrote:

    Looks .patch didn't work as an attachment, retry with .txt and
    paste the text below as well. Sorry for one more message here.

    I think this patch looks okay and I assume you'll test it in the
    jdk-submit repo to make sure it builds on all platforms.

    -Alan

RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX

[Lindenmaier, Goetz]

Hi Arno, 

thanks for looking at the change!

Best regards,
  Goetz.

> -Original Message-
> From: Zeller, Arno
> Sent: Dienstag, 22. Januar 2019 14:48
> To: Lindenmaier, Goetz 
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for
> AIX
> 
> Hi Goetz,
> 
> looks good to me and should fix the issue.
> I just want to point out that I am not a Reviewer.
> 
> Best regards,
> Arno
> 
> >-Original Message-
> >From: core-libs-dev  On Behalf Of
> >Lindenmaier, Goetz
> >Sent: Montag, 21. Januar 2019 11:01
> >To: core-libs-dev@openjdk.java.net
> >Subject: [CAUTION] RFR(XS): 8217438: Adapt
> >tools//launcher/Test7029048.java for AIX
> >
> >Hi,
> >
> >please review the following small test fix:
> >http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/
> >
> >The Aix launcher always sets the path to the jdk libraries because
> >Aix does not support $ORIGIN to find libjvm.so.
> >So some of the test cases here fail. Skip them.
> >
> >Best regards,
> >  Goetz.

RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX

[Zeller, Arno]

Hi Goetz,

looks good to me and should fix the issue.
I just want to point out that I am not a Reviewer.

Best regards,
Arno

>-Original Message-
>From: core-libs-dev  On Behalf Of
>Lindenmaier, Goetz
>Sent: Montag, 21. Januar 2019 11:01
>To: core-libs-dev@openjdk.java.net
>Subject: [CAUTION] RFR(XS): 8217438: Adapt
>tools//launcher/Test7029048.java for AIX
>
>Hi,
>
>please review the following small test fix:
>http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/
>
>The Aix launcher always sets the path to the jdk libraries because
>Aix does not support $ORIGIN to find libjvm.so.
>So some of the test cases here fail. Skip them.
>
>Best regards,
>  Goetz.

RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for AIX

[Lindenmaier, Goetz]

Hi Christoph, 

thanks for your review. I'll update AIX to Aix before pushing.

Best regards,
  Goetz.

> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 21. Januar 2019 11:43
> To: Lindenmaier, Goetz 
> Cc: core-libs-dev@openjdk.java.net
> Subject: RE: RFR(XS): 8217438: Adapt tools//launcher/Test7029048.java for
> AIX
> 
> Hi Goetz,
> 
> looks good to me. I think it should rather be "AIX" than "Aix" in the output 
> text
> - but it's a developer trace only, so probably nobody cares. 
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: core-libs-dev  On Behalf
> > Of Lindenmaier, Goetz
> > Sent: Montag, 21. Januar 2019 11:01
> > To: core-libs-dev@openjdk.java.net
> > Subject: [CAUTION] RFR(XS): 8217438: Adapt
> > tools//launcher/Test7029048.java for AIX
> >
> > Hi,
> >
> > please review the following small test fix:
> > http://cr.openjdk.java.net/~goetz/wr19/8217438-aix_launcherTest/01/
> >
> > The Aix launcher always sets the path to the jdk libraries because
> > Aix does not support $ORIGIN to find libjvm.so.
> > So some of the test cases here fail. Skip them.
> >
> > Best regards,
> >   Goetz.

Re: High memory usage / leaks was: Best mailing list for JVM embedding

[Alan Bateman]

On 22/01/2019 4:48 am, Robert Marcano wrote:

:

So the question now is, why signed jars could affect the memory usage 
of an application (we aren't doing JAR verification on our custom 
launcher, yet), just by being on the java.class.path? IIRC the 
initial application classpath JARs were never verified previously (by 
the java launcher alone, without JNLP around).


Note: Tested with JARs signed with a self signed certificate and with 
one signed with a private CA. At most, signing the JARs could slow 
down the start up if it is now expected to these being verified by 
the java launcher (is it true?) but not higher memory usage and no 
reductions after a GC cycle but constants heap size increases.
Signed JARs can be expensive to verify, esp. on first usage as the 
verification is likely to result in early loading of a lot of security 
classes and infrastructure. If you can narrow down the apparently memory 
leak to a small test case with analysis to suggest it's a JDK bug then 
it would be good to get a bug submitted.


-Alan