Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

[Thomas Stüfe]

Hi Hans,

thanks for the hint!

But how would I do this for my problem:

Allocate memory, zero it out and then store the pointer into a variable
seen by other threads, while preventing the other threads from seeing . I
do not understand how atomics would help: I can make the pointer itself an
atomic, but that only guarantees memory ordering in regard to this
variable, not to the allocated memory.

Kind Regards, Thomas




On Wed, Mar 2, 2016 at 2:27 AM, Hans Boehm  wrote:

> The preferred C11 solution is to use atomics.  Using just memory fences
> here is tricky, and not fully correct, since data races have undefined
> semantics in C (and Posix).
>
>
> On Tue, Mar 1, 2016 at 12:56 PM, David Holmes 
> wrote:
>
>> On 1/03/2016 11:39 PM, Dmitry Samersoff wrote:
>>
>>> Thomas,
>>>
>>> We probably can do:
>>>
>>> if (fdTable[rootArrayIndex] != NULL) {
>>> entryTable = fdTable[rootArrayIndex];
>>> }
>>> else { // existing code
>>>pthread_mutex_lock(&fdTableLock);
>>>if (fdTable[rootArrayIndex] == NULL) {
>>>
>>>}
>>> }
>>>
>>
>> This is double-checked locking and it requires memory barriers to be
>> correct - as Thomas already discussed.
>>
>> David
>>
>>
>> -Dmitry
>>>
>>>
>>> On 2016-03-01 16:13, Thomas Stüfe wrote:
>>>
 Dmitry, Christoph,

 I am not 100% sure this would work for weak ordering platforms.

 If I understand you correctly you suggest the double checking pattern:

 if (basetable[index] == NULL) {
  lock
  if (basetable[index] == NULL) {
  basetable[index] = calloc(size);
  }
   unlock
 }

 The problem I cannot wrap my head around is how to make this safe for
 all platforms. Note: I am not an expert for this.

 How do you prevent the "reading thread reads partially initialized
 object" problem?

 Consider this: We need to allocate memory, set it completely to zero and
 then store a pointer to it in basetable[index]. This means we have
 multiple stores - one store for the pointer, n stores for zero-ing out
 the memory, and god knows how many stores the C-Runtime allcoator needs
 to update its internal structures.

 On weak ordering platforms like ppc (and arm?), the store for
 basetable[index] may be visible before the other stores, so the reading
 threads, running on different CPUs, may read a pointer to partially
 initialized memory. What you need is a memory barrier between the
 calloc() and store of basetable[index], to prevent the latter store from
 floating above the other stores.

 I did not find anything about multithread safety in the calloc() docs,
 or guaranteed barrier behaviour, nor did I expect anything. In the
 hotspot we have our memory barrier APIs, but in the JDK I am confined to
 basic C and there is no way that I know of to do memory barriers with
 plain Posix APIs.

 Bottomline, I am not sure. Maybe I am too cautious here, but I do not
 see a way to make this safe without locking the reader thread too.

 Also, we are about to do an IO operation - is a mutex really that bad
 here? Especially with the optimization Roger suggested of pre-allocating
 the basetable[0] array and omitting lock protection there?

 Kind Regards,

 Thomas




 On Tue, Mar 1, 2016 at 11:47 AM, Langer, Christoph
 mailto:christoph.lan...@sap.com>> wrote:

  Hi Dmitry, Thomas,

  Dmitry, I think you are referring to an outdated version of the
  webrev, the current one is this:

 http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.01/webrev/

  However, I agree - the lock should probably not be taken every time
  but only in the case where we find the entry table was not yet
  allocated.

  So, maybe getFdEntry should always do this:
  entryTable = fdTable[rootArrayIndex]; // no matter if
 rootArrayIndex
  is 0

  Then check if entryTable is NULL and if yes then enter a guarded
  section which does the allocation and before that checks if another
  thread did it already.

  Also I'm wondering if the entryArrayMask and the rootArrayMask
  should be calculated once in the init() function and stored in a
  static field? Because right now it is calculated every time
  getFdEntry() is called and I don't think this would be optimized by
  inlining...

  Best regards
  Christoph

  -Original Message-
  From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net
  ] On Behalf Of
 Dmitry
  Samersoff
  Sent: Dienstag, 1. März 2016 11:20
  To: Thomas Stüfe >>>  >; Java Core Lib

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

[Andrew Haley]

On 01/03/16 10:20, Dmitry Samersoff wrote:
> The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
>> The Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/

Why use calloc here?  Surely it makes more sense to use
mmap(MAP_NORESERVE), at least on linux.  We're probably only
going to be using a small number of FDs, and there's no real
point reserving a big block of memory we won't use.

Andrew.

Re: RFR 8148187 : Remove OS X-specific com.apple.concurrent package

[Alan Bateman]

On 01/03/2016 21:16, Brent Christian wrote:


For your review is a webrev of this change:
http://cr.openjdk.java.net/~bchristi/8148187/webrev.01/
This looks good to me, in particular the move of FileManager.m into the 
right source tree as it was just wrong for that to be in jdk.deploy.osx 
when the com.apple.eio classes are in the java.desktop module.


-Alan.

Re: RFR(s): 8150460: (linux|bsd|aix)_close.c: file descriptor table may become large or may not work at all

[Thomas Stüfe]

Hi Andrew,

On Wed, Mar 2, 2016 at 9:28 AM, Andrew Haley  wrote:

> On 01/03/16 10:20, Dmitry Samersoff wrote:
> > The bug: https://bugs.openjdk.java.net/browse/JDK-8150460
> >> The Webrev:
> >>
> http://cr.openjdk.java.net/~stuefe/webrevs/8150460-linux_close-fdTable/webrev.00/webrev/
>
> Why use calloc here?  Surely it makes more sense to use
> mmap(MAP_NORESERVE), at least on linux.  We're probably only
> going to be using a small number of FDs, and there's no real
> point reserving a big block of memory we won't use.
>
> Andrew.
>
>
I am aware of this. I do not allocate all memory in one go, I allocate on
demand in n-sized-steps - that was the point of my implementation as a
sparse array.

Changing my implementation to mmap(MAP_NORESERVE) would not make the code
simpler:

I would have to commit the memory before usage. So, I have to put some
committed-pages-management atop the reserved range to keep track of which
pages are committed, which aren't. File descriptors come in in no
predictable order (usually sequentially, but there is no guarantee), so I
cannot use a simple watermark model either, where I commit pages to cover
the highest file descriptor. I mean I could, but that would be potentially
wasteful if you have big holes in file descriptor value ranges.

In the end I would end up with exactly the same implementation I have now,
only swapping mmap(MAP_RESERVE) for calloc() and driving up reserved memory
size for this process. And arguably, an even more complicated
implementation.

..Thomas

RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[nadeesh tv]

Hi all,

Please review an enhancement  for a  garbage free epochSecond method.

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



webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01 



--
Thanks and Regards,
Nadeesh TV

Re: RFR (XS): 8149596: Remove java.nio.Bits copy wrapper methods

[Paul Sandoz]

> On 1 Mar 2016, at 19:29, Mikael Vidstedt  wrote:
> 
> 
> As part of JDK-8141491[1] the native methods in java.nio.Bits were removed, 
> and the functionality is instead provided by the VM through j.i.m.Unsafe. The 
> Bits wrapper methods are therefore redundant and can be removed.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149596
> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8149596/webrev.00/webrev/
> 

+1

Paul.

> I've run the java/nio jtreg tests and it all passes (modulo a couple of 
> unrelated failures).
> 
> Cheers,
> Mikael
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8141491

Re: RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

[Alan Bateman]

On 01/03/2016 16:38, Chris Hegarty wrote:

Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major
runtime version. They should be updated to use the new JDK specific Version
API.

Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API to
determine if it should be moved, or even standardized. The changes being
proposed here may need to be updated, in a trivial way, in the future, but this
issue is intending to break the dependency on sun.misc.Version so that
8150162 [2] can make progress. Additionally, the future refactoring will most
likely be trivial.

http://cr.openjdk.java.net/~chegar/8150976/
https://bugs.openjdk.java.net/browse/JDK-8150976


Looks okay to me.

-Alan.

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[Stephen Colebourne]

Remove "Subclass can override the default implementation for a more
efficient implementation." as it adds no value.

In the default implementation of

epochSecond(Era era, int yearofEra, int month, int dayOfMonth,
int hour, int minute, int second, ZoneOffset zoneOffset)

use

prolepticYear(era, yearOfEra)

and call the other new epochSecond method. See dateYearDay(Era era,
int yearOfEra, int dayOfYear) for the design to copy. If this is done,
then there is no need to override the method in IsoChronology.

In the test,

LocalDate.MIN.with(chronoLd)

could be

LocalDate.from(chronoLd)

Thanks
Stephen






On 2 March 2016 at 10:30, nadeesh tv  wrote:
> Hi all,
>
> Please review an enhancement  for a  garbage free epochSecond method.
>
> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8030864
>
> webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01
>
> --
> Thanks and Regards,
> Nadeesh TV
>

RFR(M): 8150832: split T8139885 into several tests by functionality

[Michael Haupt]

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8150832
Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00

This is a refactoring; the monolithic test for JEP 274 was split into several 
tests along functionality covered. Also, data providers and other declarative 
annotations were introduced where it made sense.

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(M): 8150832: split T8139885 into several tests by functionality

[Claes Redestad]

Hi,

this looks good to me.

Maybe rename LoopTest to LoopCombinatorTest to add a bit of specificity?

/Claes

On 2016-03-02 13:46, Michael Haupt wrote:

Dear all,

please review this change.
RFE: https://bugs.openjdk.java.net/browse/JDK-8150832
Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00

This is a refactoring; the monolithic test for JEP 274 was split into several 
tests along functionality covered. Also, data providers and other declarative 
annotations were introduced where it made sense.

Thanks,

Michael

Re: RFR(M): 8150832: split T8139885 into several tests by functionality

[Michael Haupt]

Hi Claes,

thanks a lot, and I agree with the renaming.

Best,

Michael

> Am 02.03.2016 um 13:59 schrieb Claes Redestad :
> 
> Hi,
> 
> this looks good to me.
> 
> Maybe rename LoopTest to LoopCombinatorTest to add a bit of specificity?
> 
> /Claes
> 
> On 2016-03-02 13:46, Michael Haupt wrote:
>> Dear all,
>> 
>> please review this change.
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8150832
>> Webrev: http://cr.openjdk.java.net/~mhaupt/8150832/webrev.00
>> 
>> This is a refactoring; the monolithic test for JEP 274 was split into 
>> several tests along functionality covered. Also, data providers and other 
>> declarative annotations were introduced where it made sense.
>> 
>> Thanks,
>> 
>> Michael
>> 
> 

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(XS): 8150953: j.l.i.MethodHandles: example section in whileLoop(...) provides example for doWhileLoop

[Paul Sandoz]

> On 1 Mar 2016, at 14:46, Michael Haupt  wrote:
> 
> Dear all,
> 
> please review this fix.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150953
> Webrev: http://cr.openjdk.java.net/~mhaupt/8150953/webrev.00/
> 

+1

Paul.

> The API docs and corresponding JavaDocExampleTest test case for 
> MethodHandles.whileLoop() wrongly used the example for 
> MethodHandles.doWhileLoop().
> 
> Thanks,
> 
> Michael

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

[Amy Lu]

Please help to review the updated version:
http://cr.openjdk.java.net/~amlu/8038330/webrev.01/

Thanks,
Amy

On 3/1/16 7:41 PM, Peter Levart wrote:

Hi Amy,

I think that the following test:

 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now) 
>= 0L)) {


...will always be false. Therefore, the test will always succeed.

Perhaps you wanted to test the following:

assert start <= end;
if (start > now || now > end) { ...


Regards, Peter

On 03/01/2016 07:11 AM, Amy Lu wrote:

Please review the patch for test tools/jar/JarEntryTime.java

In which two issues fixed:

1. Test fails intermittently on checking the extracted files' 
last-modified-time are the current times.
   Instead of compare the file last-modified-time with pre-saved time 
value “now” (which is the time *before* current time, especially in a 
slow run, the time diff of “now” and current time is possible greater 
than 2 seconds precision (PRECISION)), test now compares the 
extracted file’s last-modified-time with newly created file 
last-modified-time.

2. Test may fail if run during the Daylight Saving Time change.


bug: https://bugs.openjdk.java.net/browse/JDK-8038330
webrev: http://cr.openjdk.java.net/~amlu/8038330/webrev.00/

Thanks,
Amy

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[nadeesh tv]

Hi,
Stephen, Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.02/

Regards,
Nadeesh TV

On 3/2/2016 5:41 PM, Stephen Colebourne wrote:

Remove "Subclass can override the default implementation for a more
efficient implementation." as it adds no value.

In the default implementation of

epochSecond(Era era, int yearofEra, int month, int dayOfMonth,
int hour, int minute, int second, ZoneOffset zoneOffset)

use

prolepticYear(era, yearOfEra)

and call the other new epochSecond method. See dateYearDay(Era era,
int yearOfEra, int dayOfYear) for the design to copy. If this is done,
then there is no need to override the method in IsoChronology.

In the test,

LocalDate.MIN.with(chronoLd)

could be

LocalDate.from(chronoLd)

Thanks
Stephen






On 2 March 2016 at 10:30, nadeesh tv  wrote:

Hi all,

Please review an enhancement  for a  garbage free epochSecond method.

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

webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01

--
Thanks and Regards,
Nadeesh TV



--
Thanks and Regards,
Nadeesh TV

RFR: 8147755: ASM should create correct constant tag for invokestatic on handle point to interface static method

[Kumar Srinivasan]

Hello Remi, et. al.,

Webrev:
http://cr.openjdk.java.net/~ksrini/8147755/webrev.00/

Can you please approve this patch, it is taken out of ASM's svn repo.
change id 1795,  which addresses the problem described in [1].

Note 1: A couple of @Deprecated annotations and doc comments
have been disabled, because we have a catch-22 that an internal and closed
component depends on these APIs, and the replacement is not available until
we push this patch. A follow up bug [2] has been filed.

Note 2: jprt tested, all core-libs, langtools and nashorn regressions
pass. HotSpot team has verified that it address their issues.


Thank you
Kumar

[1] https://bugs.openjdk.java.net/browse/JDK-8147755
[2] https://bugs.openjdk.java.net/browse/JDK-8151056

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[Stephen Colebourne]

I think that this is fine now, but Roger/others should also chime in.
thanks
Stephen

On 2 March 2016 at 15:17, nadeesh tv  wrote:
> Hi,
> Stephen, Thanks for the comments.
> Please see the updated webrev
> http://cr.openjdk.java.net/~ntv/8030864/webrev.02/
>
> Regards,
> Nadeesh TV
>
>
> On 3/2/2016 5:41 PM, Stephen Colebourne wrote:
>>
>> Remove "Subclass can override the default implementation for a more
>> efficient implementation." as it adds no value.
>>
>> In the default implementation of
>>
>> epochSecond(Era era, int yearofEra, int month, int dayOfMonth,
>> int hour, int minute, int second, ZoneOffset zoneOffset)
>>
>> use
>>
>> prolepticYear(era, yearOfEra)
>>
>> and call the other new epochSecond method. See dateYearDay(Era era,
>> int yearOfEra, int dayOfYear) for the design to copy. If this is done,
>> then there is no need to override the method in IsoChronology.
>>
>> In the test,
>>
>> LocalDate.MIN.with(chronoLd)
>>
>> could be
>>
>> LocalDate.from(chronoLd)
>>
>> Thanks
>> Stephen
>>
>>
>>
>>
>>
>>
>> On 2 March 2016 at 10:30, nadeesh tv  wrote:
>>>
>>> Hi all,
>>>
>>> Please review an enhancement  for a  garbage free epochSecond method.
>>>
>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8030864
>>>
>>> webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01
>>>
>>> --
>>> Thanks and Regards,
>>> Nadeesh TV
>>>
>
> --
> Thanks and Regards,
> Nadeesh TV
>

Re: RFR [9] 8150976: JarFile and MRJAR tests should use the JDK specific Version API

[Mandy Chung]

> On Mar 1, 2016, at 8:38 AM, Chris Hegarty  wrote:
> 
> Currently JarFile and MRJAR tests use sun.misc.Version to retrieve the major
> runtime version. They should be updated to use the new JDK specific Version
> API. 
> 
> Note: There is an issue, 8144062 [1], to revisit the JDK specific Version API 
> to
> determine if it should be moved, or even standardized. The changes being
> proposed here may need to be updated, in a trivial way, in the future, but 
> this
> issue is intending to break the dependency on sun.misc.Version so that
> 8150162 [2] can make progress. Additionally, the future refactoring will most
> likely be trivial. 
> 
> http://cr.openjdk.java.net/~chegar/8150976/
> https://bugs.openjdk.java.net/browse/JDK-8150976
> 

+1

Mandy

[8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

[Ivan Gerasimov]

Hello!

I'm seeking for approval to backport this fix into jdk8u-dev.
Comparing to Jdk9, the patch had to be changed mainly due to compact 
string support introduced in jdk9.
However, the fix is essentially the same: we just avoid getting too 
close to Integer.MAX_VALUE when doing reallocations unless explicitly 
required.


Would you please help review it?

Bug: https://bugs.openjdk.java.net/browse/JDK-8149330
Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/123593aacb48
Jdk9 review:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039018.html
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039182.html
Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8149330/04/webrev/

Sincerely yours,
Ivan

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[Roger Riggs]

Hi Nadeesh,

Editorial comments:

Chronology.java: 716+
  "Java epoch"  -> "epoch"
  "minute, second and zoneOffset"  ->  "minute, second*,* and 
zoneOffset"  (add a comma; two places)
  "caluculated using given era, prolepticYear," -> "calculated using 
the era, year-of-era,"

  "to represent" ->  remove as unnecessary in all places

IsoChronology:
  "to represent" ->  remove as unnecessary in all places

These should be fixed to cleanup the specification.

The implementation and the tests look fine.

Thanks, Roger



On 3/2/2016 10:17 AM, nadeesh tv wrote:

Hi,
Stephen, Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.02/

Regards,
Nadeesh TV

On 3/2/2016 5:41 PM, Stephen Colebourne wrote:

Remove "Subclass can override the default implementation for a more
efficient implementation." as it adds no value.

In the default implementation of

epochSecond(Era era, int yearofEra, int month, int dayOfMonth,
int hour, int minute, int second, ZoneOffset zoneOffset)

use

prolepticYear(era, yearOfEra)

and call the other new epochSecond method. See dateYearDay(Era era,
int yearOfEra, int dayOfYear) for the design to copy. If this is done,
then there is no need to override the method in IsoChronology.

In the test,

LocalDate.MIN.with(chronoLd)

could be

LocalDate.from(chronoLd)

Thanks
Stephen






On 2 March 2016 at 10:30, nadeesh tv  wrote:

Hi all,

Please review an enhancement  for a  garbage free epochSecond method.

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

webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01

--
Thanks and Regards,
Nadeesh TV

RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Coleen Phillimore]

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement, 
with JVM_GetStackTraceElements that gets all the elements in the 
StackTraceElement[]


These improvements were found during the investigation for replacing 
Throwable with the StackWalkAPI.   This change also adds iterator for 
BacktraceBuilder to make changing format of backtrace easier.


Tested with -testset core, RBT nightly hotspot nightly tests on all 
platforms, and jck tests on linux x64.  Compatibility request is approved.


open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/
open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot
bug link https://bugs.openjdk.java.net/browse/JDK-8150778

Thanks,
Coleen

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

[nadeesh tv]

Hi ,

Please see the updated webrev 
http://cr.openjdk.java.net/~ntv/8030864/webrev.03/


Thanks and Regards,
Nadeesh

On 3/3/2016 12:01 AM, Roger Riggs wrote:

Hi Nadeesh,

Editorial comments:

Chronology.java: 716+
  "Java epoch"  -> "epoch"
  "minute, second and zoneOffset"  ->  "minute, second*,* and 
zoneOffset"  (add a comma; two places)
  "caluculated using given era, prolepticYear," -> "calculated using 
the era, year-of-era,"

  "to represent" ->  remove as unnecessary in all places

IsoChronology:
  "to represent" ->  remove as unnecessary in all places

These should be fixed to cleanup the specification.

The implementation and the tests look fine.

Thanks, Roger



On 3/2/2016 10:17 AM, nadeesh tv wrote:

Hi,
Stephen, Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8030864/webrev.02/

Regards,
Nadeesh TV

On 3/2/2016 5:41 PM, Stephen Colebourne wrote:

Remove "Subclass can override the default implementation for a more
efficient implementation." as it adds no value.

In the default implementation of

epochSecond(Era era, int yearofEra, int month, int dayOfMonth,
int hour, int minute, int second, ZoneOffset zoneOffset)

use

prolepticYear(era, yearOfEra)

and call the other new epochSecond method. See dateYearDay(Era era,
int yearOfEra, int dayOfYear) for the design to copy. If this is done,
then there is no need to override the method in IsoChronology.

In the test,

LocalDate.MIN.with(chronoLd)

could be

LocalDate.from(chronoLd)

Thanks
Stephen






On 2 March 2016 at 10:30, nadeesh tv  wrote:

Hi all,

Please review an enhancement  for a  garbage free epochSecond method.

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

webrev: http://cr.openjdk.java.net/~ntv/8030864/webrev.01

--
Thanks and Regards,
Nadeesh TV







--
Thanks and Regards,
Nadeesh TV

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Daniel Fuchs]

Hi Coleen,

Nice improvement!

Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/

1. StackTraceElement.java

Does the new constructor in StackTraceElement really need to be
public? Can't we keep that package protected?

2. Throwable.java:902

902  * package-protection for use by SharedSecrets.

If I'm not mistaken we removed the shared secrets access - IIRC that
was used by java.util.logging.LogRecord  - which now uses the
StackWalker API instead.

So maybe you could make the method private and remove the comment
as further cleanup.

Please don't count me as (R)eviewer for the hotspot changes :-)

best regards,

-- daniel

On 02/03/16 19:44, Coleen Phillimore wrote:

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement,
with JVM_GetStackTraceElements that gets all the elements in the
StackTraceElement[]

These improvements were found during the investigation for replacing
Throwable with the StackWalkAPI.   This change also adds iterator for
BacktraceBuilder to make changing format of backtrace easier.

Tested with -testset core, RBT nightly hotspot nightly tests on all
platforms, and jck tests on linux x64.  Compatibility request is approved.

open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/
open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot
bug link https://bugs.openjdk.java.net/browse/JDK-8150778

Thanks,
Coleen

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Aleksey Shipilev]

Hi Coleen,

On 03/02/2016 09:44 PM, Coleen Phillimore wrote:
> Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement,
> with JVM_GetStackTraceElements that gets all the elements in the
> StackTraceElement[]
> 
> These improvements were found during the investigation for replacing
> Throwable with the StackWalkAPI.   This change also adds iterator for
> BacktraceBuilder to make changing format of backtrace easier.
> 
> Tested with -testset core, RBT nightly hotspot nightly tests on all
> platforms, and jck tests on linux x64.  Compatibility request is approved.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/
> open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot
> bug link https://bugs.openjdk.java.net/browse/JDK-8150778

Looks interesting!

Is there an underlying reason why we can't return the pre-filled
StackTraceElements[] array from the JVM_GetStackTraceElements to begin
with? This will avoid leaking StackTraceElement constructor into
standard library, *and* allows to make StackTraceElement fields final.
Taking stuff back from the standard library is hard, if not impossible,
so we better expose as little as possible.

Other minor nits:

 * Initializing fields to their default values is a code smell in Java:
 private transient int depth = 0;

 * Passing a null array to getStackTraceElement probably SEGVs? I don't
see the null checks in native parts.

Thanks,
-Aleksey

Custom security policy without replacing files in the OpenJDK?

[Marcus Lagergren]

Hi!

Is it possible to override lib/security/local_policy on app level without 
patching jdk distro?
i.e. -Duse.this.policy.jar= … or something?

Can’t find a way to do it

Regards
Marcus

Re: Replacement of Quicksort in java.util.Arrays with new Dual-Pivot Quicksort

[Jason C. McDonald]

Hi Stuart,

I hate replying to an ancient threat, but I figured it was the best 
method. Thanks for the tips. The original paper was almost as hard to 
find as he is proving to be. :)


All the best,

-Jason C. McDonald

On 02/26/2016 06:05 PM, Stuart Marks wrote:

Wow, is this a reply to a nearly seven-year-old email? [1]

I don't know if Vladimir Yaroslavskiy is still on core-libs-dev. I dug 
through tthe archives and found that he had posted a couple messages 
somewhat later [2] [3] using different email addresses:


  Vladimir Iaroslavski 
  Vladimir Iaroslavski 

You might try to contact him at one of these addresses. Note however 
that the more recent one is still over five years old.


He's also on LinkedIn. His profile says he works for Oracle, but as 
far as I can see he no longer does.


Good luck,

s'marks


[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-September/002630.html


[2] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/004133.html


[3] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-February/005821.html




On 2/23/16 6:05 PM, Jason C. McDonald wrote:

I think this is the best place to contact the original authors.

The link to Vladimir Yaroslavskiy's original whitepaper describing the
algorithm and its proofs was, unfortunately, broken. Using Archive.org's
Wayback Machine, I was able to get the last known revision. I 
reformatted

the document in LibreOffice for ease of reading, and fixed some minor
grammatical errors.

I also implemented the algorithm in an open-source (MIT License) C++
library, which I hope to release in the coming few months.

In order to make this algorithm and its proofs more easily accessible, I
would like to make the revised whitepaper publicly and freely 
available from
my own web servers, but I wanted to check with the original author(s) 
first.
Furthermore, I wanted to find out if there have been any revisions 
since the

22 September 2009 version of the whitepaper I acquired.

Thank you in advance!



--
Jason C. McDonald

Check out my scribblings!
www.indeliblebluepen.com

RFR 8150679: closed/javax/crypto/CryptoPermission/CallerIdentification.sh fails after fix for JDK-8132734

[Steve Drach]

Please review the following fix for JDK-8150679

webrev: http://cr.openjdk.java.net/~sdrach/8150679/webrev/ 

issue: https://bugs.openjdk.java.net/browse/JDK-8150679 


The test was modified to demonstrate the problem.

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Coleen Phillimore]

Hi Daniel,
Thank you for looking at this so quickly.

On 3/2/16 1:57 PM, Daniel Fuchs wrote:

Hi Coleen,

Nice improvement!

Two remarks on http://cr.openjdk.java.net/~coleenp/8150778_jdk/

1. StackTraceElement.java

Does the new constructor in StackTraceElement really need to be
public? Can't we keep that package protected?


So I just removed the public keyword, and that seems good.  Thanks!



2. Throwable.java:902

902  * package-protection for use by SharedSecrets.

If I'm not mistaken we removed the shared secrets access - IIRC that
was used by java.util.logging.LogRecord  - which now uses the
StackWalker API instead.

So maybe you could make the method private and remove the comment
as further cleanup.


I had just copied the SharedSecrets comments.  I'll make 
getStackTraceElements private also.




Please don't count me as (R)eviewer for the hotspot changes :-)


Oh, but you know this code in hotspot, now.  That's ok, you don't need 
to review hotspot code.


Thanks!
Coleen



best regards,

-- daniel

On 02/03/16 19:44, Coleen Phillimore wrote:

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement,
with JVM_GetStackTraceElements that gets all the elements in the
StackTraceElement[]

These improvements were found during the investigation for replacing
Throwable with the StackWalkAPI.   This change also adds iterator for
BacktraceBuilder to make changing format of backtrace easier.

Tested with -testset core, RBT nightly hotspot nightly tests on all
platforms, and jck tests on linux x64.  Compatibility request is 
approved.


open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/
open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot
bug link https://bugs.openjdk.java.net/browse/JDK-8150778

Thanks,
Coleen

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

[Xueming Shen]

+1

though it might be better (?) to check as

184 if (now<  start || now>  end)) {

thanks,
sherman


On 03/02/2016 06:23 AM, Amy Lu wrote:

Please help to review the updated version:
http://cr.openjdk.java.net/~amlu/8038330/webrev.01/

Thanks,
Amy

On 3/1/16 7:41 PM, Peter Levart wrote:

Hi Amy,

I think that the following test:

 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now) >= 0L)) {

...will always be false. Therefore, the test will always succeed.

Perhaps you wanted to test the following:

assert start <= end;
if (start > now || now > end) { ...


Regards, Peter

On 03/01/2016 07:11 AM, Amy Lu wrote:

Please review the patch for test tools/jar/JarEntryTime.java

In which two issues fixed:

1. Test fails intermittently on checking the extracted files' 
last-modified-time are the current times.
   Instead of compare the file last-modified-time with pre-saved time value 
“now” (which is the time *before* current time, especially in a slow run, the 
time diff of “now” and current time is possible greater than 2 seconds 
precision (PRECISION)), test now compares the extracted file’s 
last-modified-time with newly created file last-modified-time.
2. Test may fail if run during the Daylight Saving Time change.


bug: https://bugs.openjdk.java.net/browse/JDK-8038330
webrev: http://cr.openjdk.java.net/~amlu/8038330/webrev.00/

Thanks,
Amy

RFR(S): 8150957: j.l.i.MethodHandles.whileLoop(...) fails with IOOBE in the case 'init' is null, 'step' and 'pred' have parameters

[Michael Haupt]

Dear all,

please review this change.
Bug: https://bugs.openjdk.java.net/browse/JDK-8150957
Webrev: http://cr.openjdk.java.net/~mhaupt/8150957/webrev.00/

The bug was actually fixed with the push for JDK-8150635. This change adds a 
test for the issue.

Thanks,

Michael

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Coleen Phillimore]

On 3/2/16 1:58 PM, Aleksey Shipilev wrote:

Hi Coleen,

On 03/02/2016 09:44 PM, Coleen Phillimore wrote:

Summary: replace JVM_GetStackTraceDepth and JVM_GetStackTraceElement,
with JVM_GetStackTraceElements that gets all the elements in the
StackTraceElement[]

These improvements were found during the investigation for replacing
Throwable with the StackWalkAPI.   This change also adds iterator for
BacktraceBuilder to make changing format of backtrace easier.

Tested with -testset core, RBT nightly hotspot nightly tests on all
platforms, and jck tests on linux x64.  Compatibility request is approved.

open webrev at http://cr.openjdk.java.net/~coleenp/8150778_jdk/
open webrev at http://cr.openjdk.java.net/~coleenp/8150778_hotspot
bug link https://bugs.openjdk.java.net/browse/JDK-8150778

Looks interesting!

Is there an underlying reason why we can't return the pre-filled
StackTraceElements[] array from the JVM_GetStackTraceElements to begin
with? This will avoid leaking StackTraceElement constructor into
standard library, *and* allows to make StackTraceElement fields final.
Taking stuff back from the standard library is hard, if not impossible,
so we better expose as little as possible.


We measured that it's faster to allocate the StackTraceElement array in 
Java and it seems cleaner to the Java guys.

It came from similar code we've been prototyping for StackFrameInfo.


Other minor nits:

  * Initializing fields to their default values is a code smell in Java:
  private transient int depth = 0;


ok, not sure what "code smell" means but it doesn't have to be 
initialized like this.  It's set in the native code.


  * Passing a null array to getStackTraceElement probably SEGVs? I don't
see the null checks in native parts.


Yes, it would SEGV.  I'll add some checks for null and make sure it's an 
array of StackTraceElement.


Thanks,
Coleen


Thanks,
-Aleksey

Re: [8u-dev] Request for REVIEW and APPROVAL to backport: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

[Martin Buchholz]

Reviewed!

On Wed, Mar 2, 2016 at 9:29 AM, Ivan Gerasimov
 wrote:
> Hello!
>
> I'm seeking for approval to backport this fix into jdk8u-dev.
> Comparing to Jdk9, the patch had to be changed mainly due to compact string
> support introduced in jdk9.
> However, the fix is essentially the same: we just avoid getting too close to
> Integer.MAX_VALUE when doing reallocations unless explicitly required.
>
> Would you please help review it?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149330
> Jdk9 change: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/123593aacb48
> Jdk9 review:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/039018.html
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-March/039182.html
> Jdk8 webrev: http://cr.openjdk.java.net/~igerasim/8149330/04/webrev/
>
> Sincerely yours,
> Ivan

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Aleksey Shipilev]

On 03/02/2016 10:57 PM, Coleen Phillimore wrote:
> On 3/2/16 1:58 PM, Aleksey Shipilev wrote:
>> Is there an underlying reason why we can't return the pre-filled
>> StackTraceElements[] array from the JVM_GetStackTraceElements to begin
>> with? This will avoid leaking StackTraceElement constructor into
>> standard library, *and* allows to make StackTraceElement fields final.
>> Taking stuff back from the standard library is hard, if not impossible,
>> so we better expose as little as possible.
> 
> We measured that it's faster to allocate the StackTraceElement array
> in Java and it seems cleaner to the Java guys. It came from similar
> code we've been prototyping for StackFrameInfo.

OK, it's not perfectly clean from implementation standpoint, but this
RFE might not be the best opportunity to polish that. At least make
StackTraceElement constructor private (better), or package-private
(acceptable), and then we are good to go.

Also, I think you can drop this line:
  836  int depth = getStackTraceDepth();

Thanks,
-Aleksey

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Coleen Phillimore]

On 3/2/16 3:21 PM, Aleksey Shipilev wrote:

On 03/02/2016 10:57 PM, Coleen Phillimore wrote:

On 3/2/16 1:58 PM, Aleksey Shipilev wrote:

Is there an underlying reason why we can't return the pre-filled
StackTraceElements[] array from the JVM_GetStackTraceElements to begin
with? This will avoid leaking StackTraceElement constructor into
standard library, *and* allows to make StackTraceElement fields final.
Taking stuff back from the standard library is hard, if not impossible,
so we better expose as little as possible.

We measured that it's faster to allocate the StackTraceElement array
in Java and it seems cleaner to the Java guys. It came from similar
code we've been prototyping for StackFrameInfo.

OK, it's not perfectly clean from implementation standpoint, but this
RFE might not be the best opportunity to polish that. At least make
StackTraceElement constructor private (better), or package-private
(acceptable), and then we are good to go.
Well, the RFE is intended to clean this up but I don't think there's 
agreement about what the cleanest thing is.  If the cleaner API is:


   StackTraceElement[] getStackTraceElements();

we should change it once and not twice.  I'd like to hear other opinions!

Since StackTraceElement constructor is called by Throwable it has to be 
package private but can't be private.  I have made it package private.


Also, I think you can drop this line:
   836  int depth = getStackTraceDepth();


Oh, right, I can do that.  I was hiding the field depth.  i don't need 
the function either.


Thanks! Thank you for looking at this so quickly.

Coleen



Thanks,
-Aleksey

Re: RFR: jsr166 jdk9 integration wave 5

[Martin Buchholz]

Webrevs updated, incorporating changes to tests in my previous message.

RFR: 8151098: Introduce multi-slot per-thread cache for StringDecoders/Encoders

[Tony Printezis]

Hi all,

We discussed this change in a previous e-mail thread. Here’s a patch for your 
consideration:

http://cr.openjdk.java.net/~tonyp/8151098/webrev.1/

I cloned the Cache class from ThreadLocalCoders and reworked it a bit. The 
StringDecoder and StringEncoder classes had some common fields (the Charset and 
the requested charset name). I moved them to a superclass (StringCoder) which 
made the cache easier to write (I didn’t have to create one subclass for the 
decoder and one for the encoder, as it is the case in ThreadLocalCoders).

Feedback very welcome!

Tony

-

Tony Printezis | JVM/GC Engineer / VM Team | Twitter

@TonyPrintezis
tprinte...@twitter.com

Re: Custom security policy without replacing files in the OpenJDK?

[David Holmes]

On 27/02/2016 2:56 AM, Marcus Lagergren wrote:

Hi!

Is it possible to override lib/security/local_policy on app level without 
patching jdk distro?
i.e. -Duse.this.policy.jar= … or something?

Can’t find a way to do it


http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html

Specifying an Additional Policy File at Runtime

It is also possible to specify an additional or a different policy file 
when invoking execution of an application. This can be done via the 
"-Djava.security.policy" command line argument, which sets the value of 
the java.security.policy property. For example, if you use


java -Djava.security.manager -Djava.security.policy=someURL SomeApp
...

HTH

David


Regards
Marcus

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Mandy Chung]

> On Mar 2, 2016, at 4:03 PM, Coleen Phillimore  
> wrote:
> 
> Freshly tested changes with jck tests, with missing checks and other changes 
> to use the depth field, as pointed out by Aleksey.  I've kept the 
> StackTraceElement[] allocation in Java to match the new API that was approved.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/
> open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/

typo in your link:
  http://cr.openjdk.java.net/~coleenp/8150778.02_jck/

StackTraceElement.java
 80  * @since 1.9

This is not needed. Simply take this out.

Throwable.java

215  * Native code sets the depth of the backtrace for later retrieval

s/Native code/VM/

since VM is setting the depth field.


896 private native void getStackTraceElements(StackTraceElement[] elements);

Can you add the method description
   “Gets the stack trace elements."

I only skimmed on the hotspot change.  Looks okay to me.

TestThrowable.java 

  43 int getDepth(Throwable t) throws Exception {
  44   for (Field f : Throwable.class.getDeclaredFields()) {
  45 if (f.getName().equals("depth")) {
 

You can replace the above with Throwable.class.getDeclaredField(“depth”)

Otherwise, looks okay.

Mandy

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

[Coleen Phillimore]

Mandy, thank you for reviewing this.

On 3/2/16 9:18 PM, Mandy Chung wrote:

On Mar 2, 2016, at 4:03 PM, Coleen Phillimore  
wrote:

Freshly tested changes with jck tests, with missing checks and other changes to 
use the depth field, as pointed out by Aleksey.  I've kept the 
StackTraceElement[] allocation in Java to match the new API that was approved.

open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_hotspot/
open webrev at http://cr.openjdk.java.net/~coleenp/8150778.02_jdk/

typo in your link:
   http://cr.openjdk.java.net/~coleenp/8150778.02_jck/

StackTraceElement.java
  80  * @since 1.9


Okay, good because it's probably 9.0 anyway.


This is not needed. Simply take this out.

Throwable.java

215  * Native code sets the depth of the backtrace for later retrieval

s/Native code/VM/
I changed it to "The JVM sets the depth..."  There was another sentence 
just like this for the backtrace field, which I also changed.

since VM is setting the depth field.


896 private native void getStackTraceElements(StackTraceElement[] elements);

Can you add the method description
“Gets the stack trace elements."


Fixed.

I only skimmed on the hotspot change.  Looks okay to me.

TestThrowable.java

   43 int getDepth(Throwable t) throws Exception {
   44   for (Field f : Throwable.class.getDeclaredFields()) {
   45 if (f.getName().equals("depth")) {
  


You can replace the above with Throwable.class.getDeclaredField(“depth”)


Yes, that's better.

Otherwise, looks okay.


Thanks!
Coleen

Mandy

Re: JDK 9 RFR of JDK-8038330: tools/jar/JarEntryTime.java fails intermittently on checking extracted file last modified values are the current times

[Amy Lu]

On 3/3/16 3:42 AM, Xueming Shen wrote:

+1

though it might be better (?) to check as

184 if (now<  start || now>  end)) {


Updated :-)

http://cr.openjdk.java.net/~amlu/8038330/webrev.02/

Thanks,
Amy



thanks,
sherman


On 03/02/2016 06:23 AM, Amy Lu wrote:

Please help to review the updated version:
http://cr.openjdk.java.net/~amlu/8038330/webrev.01/

Thanks,
Amy

On 3/1/16 7:41 PM, Peter Levart wrote:

Hi Amy,

I think that the following test:

 178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - 
now) >= 0L)) {


...will always be false. Therefore, the test will always succeed.

Perhaps you wanted to test the following:

assert start <= end;
if (start > now || now > end) { ...


Regards, Peter

On 03/01/2016 07:11 AM, Amy Lu wrote:

Please review the patch for test tools/jar/JarEntryTime.java

In which two issues fixed:

1. Test fails intermittently on checking the extracted files' 
last-modified-time are the current times.
   Instead of compare the file last-modified-time with pre-saved 
time value “now” (which is the time *before* current time, 
especially in a slow run, the time diff of “now” and current time 
is possible greater than 2 seconds precision (PRECISION)), test now 
compares the extracted file’s last-modified-time with newly created 
file last-modified-time.

2. Test may fail if run during the Daylight Saving Time change.


bug: https://bugs.openjdk.java.net/browse/JDK-8038330
webrev: http://cr.openjdk.java.net/~amlu/8038330/webrev.00/

Thanks,
Amy

RFR: 8059169 [Findbugs]Classes under package com.sun.tools.internal.xjc may expose internal representation by storing an externally mutable object

[Eric Guo]

Hi all,

Could you please help me to review my code change about issue 
https://bugs.openjdk.java.net/browse/JDK-8059169 ?


webrev: http://cr.openjdk.java.net/~fyuan/eguo/8059169/webrev.00/ . 
These change are only for JDK 9.


Best regards,
Eric