Re: RFR: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR

[John Rose]

Good.

Please change the comment:
s/null, no tuple change, force recomputation/null, drop ICs attribute, force CP 
recomputation/

Reordering BSMs and ICs should work.
The BSMs may need extra ICs, but ICs cannot depend on BSMs.
I wonder why we did the other order first?  I guess because that is what the 
spec. says.

Oh, there's a problem with the attribute insertion order logic; it's buggy that 
we unconditionally
insert a BSMs attr. and then delete it later.  (That goes wrong when change<0 
and we recompute
from scratch.)

Suggested amended patch enclosed.

— John

On Mar 21, 2016, at 12:49 PM, Kumar Srinivasan  
wrote:
> 
> Hi John,
> 
> This patch contains fixes for two bugs:
> 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR
> 8062335: Pack200 Java implementation differs from C version, outputs unused 
> UTF8 for BootstrapMethods Note: The test case exhibits both of the above.
> 
> With this  the classes produced by java and the native implementation are 
> congruent,
> though the JDK image's classes exhibit these issues, as a precaution I have 
> extracted the
> minimal set of classes to reproduce the issues, into the golden jar.
> 
> The webrev is at:
> http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/
> 
> Thanks
> Kumar
> 


diff --git 
a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java 
b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java
--- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java
+++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Package.java
@@ -312,6 +312,12 @@
 void setBootstrapMethods(Collection bsms) {
 assert(bootstrapMethods == null);  // do not do this twice
 bootstrapMethods = new ArrayList<>(bsms);
+// Edit the attribute list, if necessary.
+Attribute a = getAttribute(attrBootstrapMethodsEmpty);
+if (bootstrapMethods != null && a == null)
+addAttribute(attrBootstrapMethodsEmpty.canonicalInstance());
+else if (bootstrapMethods == null && a != null)
+removeAttribute(a);
 }
 
 boolean hasInnerClasses() {
diff --git 
a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java 
b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java
--- a/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java
+++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/PackageReader.java
@@ -1193,16 +1193,25 @@
 cls.visitRefs(VRM_CLASSIC, cpRefs);
 
 ArrayList bsms = new ArrayList<>();
-/*
- * BootstrapMethod(BSMs) are added here before InnerClasses(ICs),
- * so as to ensure the order. Noting that the BSMs  may be
- * removed if they are not found in the CP, after the ICs expansion.
- */
-
cls.addAttribute(Package.attrBootstrapMethodsEmpty.canonicalInstance());
 
 // flesh out the local constant pool
 ConstantPool.completeReferencesIn(cpRefs, true, bsms);
 
+// Add the BSMs and references as required.
+if (!bsms.isEmpty()) {
+// Add the attirbute name to the CP (visitRefs would have wanted 
this).
+cpRefs.add(Package.getRefString("BootstrapMethods"));
+// The pack-spec requires that BootstrapMethods precedes the 
InnerClasses attribute.
+// So add BSMs now before running expandLocalICs.
+// But first delete any local InnerClasses attr.  (This is rare.)
+List localICs = cls.getInnerClasses();
+cls.setInnerClasses(null);
+Collections.sort(bsms);
+cls.setBootstrapMethods(bsms);
+// Re-add the ICs, so the attribute lists are in the required 
order.
+cls.setInnerClasses(localICs);
+}
+
 // Now that we know all our local class references,
 // compute the InnerClasses attribute.
 int changed = cls.expandLocalICs();
@@ -1221,16 +1230,6 @@
 ConstantPool.completeReferencesIn(cpRefs, true, bsms);
 }
 
-// remove the attr previously set, otherwise add the bsm and
-// references as required
-if (bsms.isEmpty()) {
-
cls.attributes.remove(Package.attrBootstrapMethodsEmpty.canonicalInstance());
-} else {
-cpRefs.add(Package.getRefString("BootstrapMethods"));
-Collections.sort(bsms);
-cls.setBootstrapMethods(bsms);
-}
-
 // construct a local constant pool
 int numDoubles = 0;
 for (Entry e : cpRefs) {

Re: RFR: 8150469: unpack200 fails to compare crc correctly.

[John Rose]

Looks good, a clean fix.  The negative test should be called "testBadChecksum" 
or "testBrokenTrailer".

— John

On Feb 29, 2016, at 8:06 AM, Kumar Srinivasan  
wrote:
> 
> Hello John, Alex,
> 
> Please review fix for https://bugs.openjdk.java.net/browse/JDK-8150469
> 
> The previous fix keeps the storage in the unpacker object which is
> reset, for a multi-segmented pack archive, thus the computed crc32 is lost.
> 
> Now the storage is moved into the gzip container, which persists, across
> multiple segments, I  also added the length check as specified by RFC 1952,
> as  implemented by JDK.
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/e4af8119eba4/src/java.base/share/classes/java/util/zip/GZIPInputStream.java#l222
> 
> The review is at:
> http://cr.openjdk.java.net/~ksrini/8150469/webrev.00/
> 
> 
> Thanks
> Kumar
> 
> 

Re: RFR:JDK-8148849:Truncating Duration

[Roger Riggs]

Hi Nadeesh,

An internal reviewer pointed out that Duration does not have 'fields' 
(it is not a TemporalAccessor)

so the description might be clarified by saying:

+ * Truncating the duration returns a copy of the original with 
*conceptual *fields

+ * smaller than the specified unit set to zero.

The rest is fine.  Reviewed

Thanks, Roger



On 3/30/2016 9:33 AM, Stephen Colebourne wrote:

Yes, that looks OK now.
thanks
Stephen


On 30 March 2016 at 12:25, nadeesh tv  wrote:

Hi Stephen,

Thanks for the comments.
Please see the updated webrev
http://cr.openjdk.java.net/~ntv/8148849/webrev.01/

Made a change in unit == ChronoUnit.SECONDS  also


Regards,
Nadeesh TV


On 3/29/2016 6:10 PM, Stephen Colebourne wrote:

We're almost there, but looking at the tests, it looks like the
behaviour is wrong:

The intended behaviour is that
-20.5mins (minus 20 minutes 30 secs) should truncate to -20mins
-2.1secs truncate to -2secs

Note that the truncation is different to Instant here.
An Instant truncates towards the far past - like RoundingMode.FLOOR
A Duration truncates towards the zero - like RoundingMode.DOWN

Stephen


On 29 March 2016 at 13:18, nadeesh tv  wrote:

Hi all,

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

Enhanced Duration by adding   public Duration truncatedTo(TemporalUnit
unit)

Please http://cr.openjdk.java.net/~ntv/8148849/webrev.00/

--
Thanks and Regards,
Nadeesh TV


--
Thanks and Regards,
Nadeesh TV

Re: RFR: jsr166 jdk9 integration wave 6

[Martin Buchholz]

We missed Aleksey's changes, which broke our integration.

Historically, hotspot was more independent from jdk, and there were no
"flag days" that required both to be modified together.

In jsr166 CVS we still consistently use sun.misc.Unsafe, because it's
... ummm ... more portable.
Our openjdk integration script changes that to jdk.internal.misc, but
needs modification.
Most of these will sadly soon change again, due to varhandlification.

Everything regenerated, now with:

# Replaces sun.misc.Unsafe with jdk9's preferred jdk.internal.misc
find src/main -name '*.java' \
  | xargs perl -pi -0777 \
  -e 's~\bsun\.misc\.Unsafe\b~jdk.internal.misc.Unsafe~g;
  s~\bputOrdered([A-Za-z]+)\b~put${1}Release~g'

On Wed, Apr 6, 2016 at 5:54 AM, Paul Sandoz  wrote:
> Hi Martin,
>
> miscellaneous
> —
>
> You reverted Aleksey’s change s/putOrderedObject/putObjectRelease.
>
> The *Ordered* methods are now removed from the “real” 
> jdk.internal.misc.Unsafe.
>
> Paul.
>
>
>> On 3 Apr 2016, at 20:29, Martin Buchholz  wrote:
>>
>> Easy changes to review, up to April Fools day, in part to make room
>> for later unfinished more exciting changes.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
>

Re: RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file.

[Lance Andersen]

looks fine joe

> On Apr 6, 2016, at 3:33 PM, huizhe wang  wrote:
> 
> Hi,
> 
> Fix a typo in the catalog reader where the intention was to set the defer 
> attribute, but the prefer was set instead. The tests are from the JCK.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8150969
> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/webrev/
> 
> Thanks,
> Joe

 
  

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

RFR JDK 9 (JAXP) 8150969 : DEFER from Features API is taking precedence over defer preference in catalog file.

[huizhe wang]

Hi,

Fix a typo in the catalog reader where the intention was to set the 
defer attribute, but the prefer was set instead. The tests are from the 
JCK.


JBS: https://bugs.openjdk.java.net/browse/JDK-8150969
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150969/webrev/

Thanks,
Joe

Re: RFR 8153123 : Streamline StackWalker code

[Brent Christian]

On 04/05/2016 10:36 PM, Mandy Chung wrote:


Looks good.  Nit: can you add a space after “synchronized” in 
StackFrameInfo.java line 109:
  109 synchronized(this) {


Yep - changed locally.

Thanks,
-Brent

RE: RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Iris Clark]

Hi, Volker.

Sorry for the delay.  I agree that the old implementation isn't quite correct.  
I can't see us potentially having a JCP MR for a security or patch release 
(9.0.0.X and 9.0.X respectively). 

I could see a MR for an very unusual minor release (9.X).  If we had an MR 
there's no guarantee that we'd need to change the java.specification.version 
system property.   However, in the event that we did need to change the 
java.specification.version, it should match that release's $MAJOR.$MINOR, even 
if it meant that we had a sequence of specification version numbers with gaps.

As an example, let's say that JDK 9 is released via umbrella JSR with 
java.specification.value of "9".  The system property would remain at "9" for 
all releases regardless of type until we choose to have a MR.  Should that MR 
occur while we're working on minor release 9.3.X and there is a need to change 
the value of java.specification.value, it would become "9.3" and would remain 
so in every release until the next MR.

While we haven't changed the system property recently, I think that we need to 
future-proof ourselves a little bit for MRs as described above. 

Assuming that we change the syntax of java.specification.version to 
$MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make a 
similar change to the syntax of java.vm.specification.version.  [ Note that in 
the current implementation, I believe that the values of 
java.specification.version and java.vm.specification.version are tied to each 
other. ]

Changing the syntax of java{.vm}?specification.version requires a CCC which I 
will file once we have agreement on the necessary changes.

Regards,
Iris

-Original Message-
From: Volker Simonis [mailto:volker.simo...@gmail.com] 
Sent: Tuesday, April 05, 2016 10:26 AM
To: Java Core Libs
Cc: verona-...@openjdk.java.net
Subject: Re: RFR(XXS): 8149519: Investigate implementation of 
java.specification.version

Hi,

can somebody please review this trivial change?

Regards,
Volker


On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis  wrote:
> Hi,
>
> can I please have a review for this small fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
> https://bugs.openjdk.java.net/browse/JDK-8149519
>
> Currently the value of the java.specification.version property comes 
> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is 
> currently set to VERSION_NUMBER which is the same value which is also 
> used for the java.version property.
>
> This is a bad idea, because VERSION_NUMBER is a dot separated sequence 
> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e.
> for every build and/or update version). If we are configuring with 
> "--with-version-patch=1" for example, VERSION_NUMBER and java.version 
> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION 
> and java.specification.version have the same, dotted value. And it 
> breaks a lot of legacy applications which parse 
> java.specification.version as a float number. That code would still 
> work if java.specification.version would be a concrete number (e.g.
> '9' or '10').
>
> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in 
> common/autoconf/spec.gmk.in. This should be the "right value" until we 
> get a specification change during a major release which hasn't 
> happened for quite some time now.
>
> Regards,
> Volker

Re: RFR 8153123 : Streamline StackWalker code

[Coleen Phillimore]

On 4/5/16 7:48 PM, Brent Christian wrote:
Thanks, Coleen.  Coordinating method/function names on "to stack trace 
element" is a fine thing.  I've done so in the updated webrev, and 
also implemented Claes's suggestion.


http://cr.openjdk.java.net/~bchristi/8153123/webrev.01/index.html


Thank you for making this change.  It looks good!  I've reviewed this.

Coleen



-Brent
On 04/05/2016 11:25 AM, Coleen Phillimore wrote:


A correction below.

On 4/5/16 1:29 PM, Coleen Phillimore wrote:


Also meant to include core-libs-dev in the email.
Thanks,
Coleen

On 4/5/16 1:27 PM, Coleen Phillimore wrote:


Hi, I've reviewed the hotspot changes and some of the jdk changes.
This looks really good.

One comment about the jvm function names:

I think FillInStackTraceElement is too close of a name to
Throwable::fill_in_stack_trace().

-JVM_ENTRY(void, JVM_SetMethodInfo(JNIEnv *env, jobject frame))
+JVM_ENTRY(void, JVM_FillInStackTraceElement(JNIEnv *env, jobject
frame, jobject stack))
   JVMWrapper("JVM_SetMethodInfo");
- Handle stackFrame(THREAD, JNIHandles::resolve(frame));
- java_lang_StackFrameInfo::fill_methodInfo(stackFrame, THREAD);
+ Handle stack_frame_info(THREAD, JNIHandles::resolve(frame));
+ Handle stack_trace_element(THREAD, JNIHandles::resolve(stack));
+ java_lang_StackFrameInfo::fill_methodInfo(stack_frame_info,
stack_trace_element, THREAD); JVM_END


And the function is called fill_methodInfo in the javaClasses 
function.


I think the JVM and the java_lang_StackFrameInfo function names
should be closer.

I wonder if the name JVM_ToStackFrameElement() and
java_lang_StackFrameInfo::to_stack_frame_element() would be better
and then it'd match the Java name.



I meant JVM_ToStackTraceElement() and
java_lang_StackFrameInfo::to_stack_trace_element(), since it's producing
a StackTraceElement.

thanks,
Coleen

Thanks!
Coleen

On 4/4/16 9:29 PM, Mandy Chung wrote:

On Apr 4, 2016, at 4:45 PM, Brent Christian
 wrote:

Hi,

I'd like to check in some footprint and code reduction changes to
the java.lang.StackWalker implementation.

Webrev:
http://cr.openjdk.java.net/~bchristi/8153123/webrev.00/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8153123


This looks good to me.

One thing to mention is that this patch is a follow-up work from the
investigation on what it takes to enable Throwable to use
StackWalker (JDK-8141239). The current built-in VM backtrace is very
compact and performant.  We have identified and prototypes the
performance improvements if Throwable backtrace is generated using
stack walker.  There are some performance gaps that we agree to
defer JDK-8141239 to a future release and improve the footprint
performance and GC throughput concerns when MemberNames are stored
in the throwable backtrace.

Mandy

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

[Alejandro Murillo]

It was late for me, so Amy took over and fixed it
Thanks
Alejandro

On 4/6/2016 1:36 AM, Alan Bateman wrote:



On 06/04/2016 06:14, Alejandro Murillo wrote:


I'd like to push the changeset below to exclude 
java/nio/Buffer/BasicByte.java
It started failing after the hotspot snapshot was pushed to jdk9/dev 
tonight.
https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for 
that failure.


Would it be possible to add @modules java.base/jdk.internal.misc, as 
below, and not exclude these tests?


-Alan


$ hg diff -g .
diff --git a/test/java/nio/Buffer/Basic.java 
b/test/java/nio/Buffer/Basic.java

--- a/test/java/nio/Buffer/Basic.java
+++ b/test/java/nio/Buffer/Basic.java
@@ -22,6 +22,7 @@
  */

 /* @test
+ * @modules java.base/jdk.internal.misc
  * @summary Unit test for buffers
  * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 
4490253 4523725
  *  4526177 4463011 4660660 4661219 4663521 4782970 4804304 
4938424 6231529
diff --git a/test/java/nio/Buffer/CopyDirectMemory.java 
b/test/java/nio/Buffer/CopyDirectMemory.java

--- a/test/java/nio/Buffer/CopyDirectMemory.java
+++ b/test/java/nio/Buffer/CopyDirectMemory.java
@@ -25,6 +25,7 @@
  * @summary Test view buffer bulk operations for large buffers.
  * @bug 4463011
  *
+ * @modules java.base/jdk.internal.misc
  * @build Basic
  * @run main CopyDirectMemory
  */


--
Alejandro

Re: RFR: 8153293 - Stream API: Preserve SORTED and DISTINCT characteristics for boxed() and asLongStream() operations

[Paul Sandoz]

> On 4 Apr 2016, at 21:28, Stefan Zobel  wrote:
> 
> Hi Tagir,
> 
> good catch! I like the proposal.
> 

Me too. +1.

Extra bonus points to test, in addition to the tested characteristics, that the 
boxed/converted elements remain sorted/distinct :-)


>> 
>> (different longs can be converted into the same double, so DISTINCT is
>> not preserved here; not sure whether this is possible for ints)
>> 
> 
> I think IntStream.asDoubleStream() can also preserve DISTINCT as
> different ints can't be mapped to the same double.
> 

Yes, there are 53 bits to play with, which is more than enough to exactly 
represent the full range of int values.

Paul.

> 
> Math.ulp((double) Integer.MIN_VALUE) ~ 4.7E-7
> 
> in contrast to
> 
> Math.ulp((double) Long.MIN_VALUE) = 2048.0
> 
> 
> So there are more than enough doubles in the vicinity of large int
> values. It's only when ulp get's >= 1.0 that distinct integral values
> need to be mapped to the same double (that happens between 1.0E15 and
> 1.0E16 for longs). Please anyone correct me if I'm wrong.
> 
> 
> Regards,
> Stefan
> 

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Vitaly Davidovich]

So are there any bootstrap issues with VH that would preclude using it in
BufferedInputStream? Is that even known at this point? You mentioned that
VH was designed to minimize bootstrapping issues, but where's the
"minimized" line drawn?

On Wed, Apr 6, 2016 at 10:09 AM, Paul Sandoz  wrote:

>
> > On 6 Apr 2016, at 15:28, fo...@univ-mlv.fr wrote:
> >
> > > > While i fully agree in the general case, in disagree for this
> specific
> > > > case,
> > > > there are few uses of ARFU inside the JDK (or outside) but currently
> > > > because BufferedInputStream uses an ARFU, each time someone starts a
> Java
> > > > application, the VM loads ARFU and its implementation with a high
> > > > probability to no need it at all after
> > > >
> > >
> > > Does that really contribute sufficiently to slow down in start time? It
> > > really seems like a micro-optimisation.
> >
> > small streams become big rivers (i don't know the idiomatic sentence in
> English, so it's a rough translation from a French idiom),
> > "Death by a thousand cuts" is one of my favorites :).  A "flat profile"
> is another description of a similar thing.
> >
> I still remain unconvinced in this case that such changes warrant an
> increase in unsafe usage (temporary or otherwise).
>
> > In general, I agree that easy/cheap/maintainable/etc wins should be done
> even if individually they don't matter much (if that were the requirement,
> there would be no progress whatsoever).
> >
> > In this case, using Unsafe for now seems trivial; when VH is ready,
> someone is going to sweep the code anyway and this will be just one more
> place to mechanically update.  Is VH definitely going to be part of Java 9?
> If so, then perhaps no point in making this change unless it's going to be
> backported to Java 8.
> >
> > Also don't forget that releasing VarHandle API as a public API for 9 is
> vastly different from replacing all usages of Unsafe by some VarHandle
> methods inside the JDK, see Paul's answser about the bootstrap issues.
> >
>
> VHs are now in jdk9/dev. I dunno when it will rise up to the master and
> the next EA build.
>
> Paul.
>

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Claes Redestad]

On 04/06/2016 04:09 PM, Paul Sandoz wrote:

small streams become big rivers (i don't know the idiomatic sentence in 
English, so it's a rough translation from a French idiom),
"Death by a thousand cuts" is one of my favorites:).  A "flat profile" is 
another description of a similar thing.


I still remain unconvinced in this case that such changes warrant an increase 
in unsafe usage (temporary or otherwise).



I did not intend for this patch to spark any controversy - in my mind it 
was just a rather straightforward and easy way to save a few Kbs (and 
some theoretic startup time) on small program startup and I'm happy to 
withdraw it based on the feedback.


I do however think that reducing the dependency graph of things which 
are loaded in this early has merits on its own, regardless of how much 
it actually improves things. Using VHs here - or even in CHM - seems 
more controversial to me than using Unsafe to take shortcuts in 
low-level class libraries that need to boot fast and with as few 
dependencies as possible (since that allows them to be used in more places).


Thanks!

/Claes

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Remi Forax]

- Mail original -
> De: "Paul Sandoz" 
> Cc: "core-libs-dev Libs" 
> Envoyé: Mercredi 6 Avril 2016 16:09:14
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of  
> AtomicReferenceFieldUpdater with Unsafe
> 
> 
> > On 6 Apr 2016, at 15:28, fo...@univ-mlv.fr wrote:
> > 
> > > > While i fully agree in the general case, in disagree for this specific
> > > > case,
> > > > there are few uses of ARFU inside the JDK (or outside) but currently
> > > > because BufferedInputStream uses an ARFU, each time someone starts a
> > > > Java
> > > > application, the VM loads ARFU and its implementation with a high
> > > > probability to no need it at all after
> > > >
> > >
> > > Does that really contribute sufficiently to slow down in start time? It
> > > really seems like a micro-optimisation.
> > 
> > small streams become big rivers (i don't know the idiomatic sentence in
> > English, so it's a rough translation from a French idiom),
> > "Death by a thousand cuts" is one of my favorites :).  A "flat profile" is
> > another description of a similar thing.
> > 
> I still remain unconvinced in this case that such changes warrant an increase
> in unsafe usage (temporary or otherwise).

Ok, you win :)

> 
> > In general, I agree that easy/cheap/maintainable/etc wins should be done
> > even if individually they don't matter much (if that were the requirement,
> > there would be no progress whatsoever).
> > 
> > In this case, using Unsafe for now seems trivial; when VH is ready, someone
> > is going to sweep the code anyway and this will be just one more place to
> > mechanically update.  Is VH definitely going to be part of Java 9? If so,
> > then perhaps no point in making this change unless it's going to be
> > backported to Java 8.
> > 
> > Also don't forget that releasing VarHandle API as a public API for 9 is
> > vastly different from replacing all usages of Unsafe by some VarHandle
> > methods inside the JDK, see Paul's answser about the bootstrap issues.
> > 
> 
> VHs are now in jdk9/dev. I dunno when it will rise up to the master and the
> next EA build.

Oh, i didn't notice.
congrat !

> 
> Paul.
> 

Rémi

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

[Alan Bateman]

On 06/04/2016 15:20, Kumar Srinivasan wrote:

Alan,

http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/

I made the changes as you suggested below, I have retained 
Files.createDirectories,
here is why, changing it to createDirectory will throw 
FileAlreadyExistsException,
which means, that if the output zip/jar file exists then an exception 
handler is

required to ignore it. I don't think its worth the trouble.
Okay, although each directory is only visited once so I don't 
immediately see how the FileAlreadyExistsException arises, unless this 
related to sym links in the jrt file system.


In any case, the updated changes looking fine. I think I would still 
reduce some of the really long lines to make it easier for reviewers in 
the future.


-Alan

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

[Kumar Srinivasan]

Alan,

http://cr.openjdk.java.net/~ksrini/8152622/webrev.02/

I made the changes as you suggested below, I have retained 
Files.createDirectories,
here is why, changing it to createDirectory will throw 
FileAlreadyExistsException,
which means, that if the output zip/jar file exists then an exception 
handler is

required to ignore it. I don't think its worth the trouble.

Thanks

Kumar






On 06/04/2016 14:09, Kumar Srinivasan wrote:




- Is Files.createDirectories needed? The walk is specified to be 
depth first so you'll also visit parent directories first.


Yes, zipfs does not allow me to create the file without creating the 
enclosing directory
first, so if I were to do this in visitFile, then presumably I would 
have to add a
check, to prevent duplicate creation going into the provider, only to 
find a
directory already exists and return, not sure if this is what you 
want, because

preVisitDirectory does this conveniently.
I should have been clearer, I was trying to say that createDirectory 
should be sufficient here because the walk is specified to be depth 
first.






- I'm also curious about the REPLACE_EXISTING as I assume that isn't 
needed.


Oh! while I was developing in NB as a discrete/stand alone project, I 
was reusing the

same zip/jar output file,  will leave it as-is, no harm, right ?.

No harm, it just caught my eye as not needed.

-Alan

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Paul Sandoz]

> On 6 Apr 2016, at 15:28, fo...@univ-mlv.fr wrote:
> 
> > > While i fully agree in the general case, in disagree for this specific
> > > case,
> > > there are few uses of ARFU inside the JDK (or outside) but currently
> > > because BufferedInputStream uses an ARFU, each time someone starts a Java
> > > application, the VM loads ARFU and its implementation with a high
> > > probability to no need it at all after
> > >
> >
> > Does that really contribute sufficiently to slow down in start time? It
> > really seems like a micro-optimisation.
> 
> small streams become big rivers (i don't know the idiomatic sentence in 
> English, so it's a rough translation from a French idiom),
> "Death by a thousand cuts" is one of my favorites :).  A "flat profile" is 
> another description of a similar thing.
> 
I still remain unconvinced in this case that such changes warrant an increase 
in unsafe usage (temporary or otherwise).

> In general, I agree that easy/cheap/maintainable/etc wins should be done even 
> if individually they don't matter much (if that were the requirement, there 
> would be no progress whatsoever).
> 
> In this case, using Unsafe for now seems trivial; when VH is ready, someone 
> is going to sweep the code anyway and this will be just one more place to 
> mechanically update.  Is VH definitely going to be part of Java 9? If so, 
> then perhaps no point in making this change unless it's going to be 
> backported to Java 8.
> 
> Also don't forget that releasing VarHandle API as a public API for 9 is 
> vastly different from replacing all usages of Unsafe by some VarHandle 
> methods inside the JDK, see Paul's answser about the bootstrap issues.
> 

VHs are now in jdk9/dev. I dunno when it will rise up to the master and the 
next EA build.

Paul.

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

[Roger Riggs]

Hi Peter,

Since the current implementation of the old Cleaner and DirectByteBuffer 
works well and there is a
lot of work piling up against the FC date, I'm in favor of keeping it as 
it is until the possibilities
with Panama settle out.  It would best if reclamation was not GC based, 
except as a last resort.


As for the Cleaner API, it is intended to have a specific function and API.
It may be that there is some advantage/optimization in the cleaner 
implementation
at some future point but the API for general use should be concrete and 
specific.
For more specific purposes, especially internal ones like the topic 
here, separate factory methods

would be more appropriate than potential overloading and mix-in interfaces.

Roger


On 4/6/2016 2:43 AM, Peter Levart wrote:

Hi Roger,

On 04/05/2016 04:41 PM, Peter Levart wrote:

On 04/04/2016 11:50 PM, Roger Riggs wrote:
I don't see the need to change Cleaner to an interface to be able to 
provide
an additional method on CleanerImpl or a subclass and a factory 
method could

provide for a clean and very targeted interface to Bits/Direct buffer.


I would like this to be an instance method so it would naturally 
pertain to a particular Cleaner instance. Or it could be a static 
method that takes a Cleaner instance. One of my previous webrevs did 
have such method on the CleanerImpl, but I was advised to move it to 
Cleaner as a package-private method and expose it via SharedSecrets 
to internal code. I feel such "camouflage" is very awkward now that 
we have modules and other mechanisms exist. So I thought it would be 
most elegant to make Cleaner an interface so it can be extended with 
an internal interface to communicate intent in a type-safe and 
auto-discoverable way. The change to make it interface:


http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/ 



...actually simplifies implementation (33 lines removed in total) and 
could be seen as an improvement in itself.


Are you afraid that if Cleaner was an interface, others would attempt 
to make implementations of it? Now that we have default methods on 
interfaces it is easy to compatibly extend the API even if it is an 
interface so that no 3rd party implementations are immediately 
broken. Are you thinking of security implications when some code is 
handed a Cleaner instance that it doesn't trust? I don't think there 
is a utility for Cleaner instances to be passed from untrusted to 
trusted code, do you?


...even if we don't do anything for DirectByteBuffer(s) in 
java.lang.ref.Cleaner and leave things as they stand (using 
jdk.internal.ref.Cleaner), I would still make this transition to 
interface to enable possible future internal extensions to 
java.lang.ref.Cleaner. As I said, this is a source compatible change, 
but not binary compatible, so if we do it, it must be performed before 
JDK 9 ships.


Regards, Peter

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[forax]

- Mail original -

> De: "Vitaly Davidovich" 
> À: "Remi Forax" 
> Cc: "Paul Sandoz" , "core-libs-dev Libs"
> 
> Envoyé: Mercredi 6 Avril 2016 15:04:39
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> AtomicReferenceFieldUpdater with Unsafe

> On Wednesday, April 6, 2016, Remi Forax < fo...@univ-mlv.fr > wrote:

> > - Mail original -
> 
> > > De: "Paul Sandoz" < paul.san...@oracle.com >
> 
> > > Cc: "core-libs-dev Libs" < core-libs-dev@openjdk.java.net >
> 
> > > Envoyé: Mercredi 6 Avril 2016 12:37:50
> 
> > > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> > > AtomicReferenceFieldUpdater with Unsafe
> 
> > >
> 
> > >
> 
> > > > On 6 Apr 2016, at 12:10, Remi Forax < fo...@univ-mlv.fr > wrote:
> 
[...] 

> > > > While i fully agree in the general case, in disagree for this specific
> 
> > > > case,
> 
> > > > there are few uses of ARFU inside the JDK (or outside) but currently
> 
> > > > because BufferedInputStream uses an ARFU, each time someone starts a
> > > > Java
> 
> > > > application, the VM loads ARFU and its implementation with a high
> 
> > > > probability to no need it at all after
> 
> > > >
> 
> > >
> 
> > > Does that really contribute sufficiently to slow down in start time? It
> 
> > > really seems like a micro-optimisation.
> 

> > small streams become big rivers (i don't know the idiomatic sentence in
> > English, so it's a rough translation from a French idiom),
> 
> "Death by a thousand cuts" is one of my favorites :). A "flat profile" is
> another description of a similar thing.

> In general, I agree that easy/cheap/maintainable/etc wins should be done even
> if individually they don't matter much (if that were the requirement, there
> would be no progress whatsoever).

> In this case, using Unsafe for now seems trivial; when VH is ready, someone
> is going to sweep the code anyway and this will be just one more place to
> mechanically update. Is VH definitely going to be part of Java 9? If so,
> then perhaps no point in making this change unless it's going to be
> backported to Java 8.
Also don't forget that releasing VarHandle API as a public API for 9 is vastly 
different from replacing all usages of Unsafe by some VarHandle methods inside 
the JDK, see Paul's answser about the bootstrap issues. 

Rémi 

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

[Alan Bateman]

On 06/04/2016 14:09, Kumar Srinivasan wrote:




- Is Files.createDirectories needed? The walk is specified to be 
depth first so you'll also visit parent directories first.


Yes, zipfs does not allow me to create the file without creating the 
enclosing directory
first, so if I were to do this in visitFile, then presumably I would 
have to add a
check, to prevent duplicate creation going into the provider, only to 
find a
directory already exists and return, not sure if this is what you 
want, because

preVisitDirectory does this conveniently.
I should have been clearer, I was trying to say that createDirectory 
should be sufficient here because the walk is specified to be depth first.






- I'm also curious about the REPLACE_EXISTING as I assume that isn't 
needed.


Oh! while I was developing in NB as a discrete/stand alone project, I 
was reusing the

same zip/jar output file,  will leave it as-is, no harm, right ?.

No harm, it just caught my eye as not needed.

-Alan

Re: RFR: JDK-8152622: tools/pack200/Pack200Props.java timed out

[Kumar Srinivasan]

Alan,

Thanks for the review. Please see inline comments.



Creating a zip file from the classes in the jrt file system make 
sense, and should be fast.


A few comments on Utils.JrtToZip:

- the URI creation in the run() method isn't reliable, could you use 
this instead:

  URI uri = URI.create("jar:" + outFile.toURI());

Ok


- In the toZipFs method then I assume you should use 
URI.create("jrt:/"), best to stay away from URL.

Ok


- Is Files.createDirectories needed? The walk is specified to be depth 
first so you'll also visit parent directories first.


Yes, zipfs does not allow me to create the file without creating the 
enclosing directory
first, so if I were to do this in visitFile, then presumably I would 
have to add a

check, to prevent duplicate creation going into the provider, only to find a
directory already exists and return, not sure if this is what you want, 
because

preVisitDirectory does this conveniently.



- I'm also curious about the REPLACE_EXISTING as I assume that isn't 
needed.


Oh! while I was developing in NB as a discrete/stand alone project, I 
was reusing the

same zip/jar output file,  will leave it as-is, no harm, right ?.



A minor comment is that "root" rather than "p" would be nicer for the 
root directory. Personally I would avoid the really long lines as it 
makes future side-by-side reviews harder. Also throws Exception seems 
too broad but it's test code so not a big deal.


Ok


Thanks
Kumar


-Alan.

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Vitaly Davidovich]

On Wednesday, April 6, 2016, Remi Forax  wrote:

> - Mail original -
> > De: "Paul Sandoz" >
> > Cc: "core-libs-dev Libs" >
> > Envoyé: Mercredi 6 Avril 2016 12:37:50
> > Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> AtomicReferenceFieldUpdater with Unsafe
> >
> >
> > > On 6 Apr 2016, at 12:10, Remi Forax >
> wrote:
> > >
> > > - Mail original -
> > >> De: "Paul Sandoz" >
> > >> Cc: "core-libs-dev Libs"  >
> > >> Envoyé: Mercredi 6 Avril 2016 09:37:00
> > >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> > >>AtomicReferenceFieldUpdater with Unsafe
> > >>
> > >>
> > >>> On 5 Apr 2016, at 17:15, Claes Redestad  >
> > >>> wrote:
> > >>>
> > >>> On 04/04/2016 05:45 PM, Martin Buchholz wrote:
> > > I think this one is going too far.
> > >
> > > A*FU/VarHandles should are supposed to act like a go-to
> replacement for
> > > Unsafe throughout the class library, and we want to shrink the
> Unsafe
> > > exposure. Also, I don't think removing A*FU in favor of Unsafe here
> > > wins
> > > us anything: there should be no throughput hit, and we *will* load
> A*FU
> > > down the road anyway, negating the startup wins.
> > >>
> > >> +1 i would leave this one as is.
> > >>
> > >> In general same goes for the @Stable/ForceInline annotations etc. We
> > >> should
> > >> use this stuff carefully within java.base and also sparingly to
> qualifying
> > >> JDK modules.
> > >
> > > While i fully agree in the general case, in disagree for this specific
> > > case,
> > > there are few uses of ARFU inside the JDK (or outside) but currently
> > > because BufferedInputStream uses an ARFU, each time someone starts a
> Java
> > > application, the VM loads ARFU and its implementation with a high
> > > probability to no need it at all after
> > >
> >
> > Does that really contribute sufficiently to slow down in start time? It
> > really seems like a micro-optimisation.
>
> small streams become big rivers (i don't know the idiomatic sentence in
> English, so it's a rough translation from a French idiom),

"Death by a thousand cuts" is one of my favorites :).  A "flat profile" is
another description of a similar thing.

In general, I agree that easy/cheap/maintainable/etc wins should be done
even if individually they don't matter much (if that were the requirement,
there would be no progress whatsoever).

In this case, using Unsafe for now seems trivial; when VH is ready, someone
is going to sweep the code anyway and this will be just one more place to
mechanically update.  Is VH definitely going to be part of Java 9? If so,
then perhaps no point in making this change unless it's going to be
backported to Java 8.

currently the main problem is that the loading of modules adds so much
> overhead to the startup time that you see nothing :(
>
> Also, startup time is one aspect, size of the VM data structures at
> runtime, size of the CDS archive* are also impacted.
>
> >
> >
> > > ARFU are not a replacement of Unsafe, VarHandles are. So adding a new
> usage
> > > of Unsafe for a good reason goes in the right direction here,
> > > when VarHandle will replace usages of Unsafe, the code of
> > > BufferedInputStream will be refactored again.
> > >
> >
> > My preference is not to change it if it’s gonna change later on.
>
> but there is also a good chance to miss that change later because you will
> look for usages of Unsafe and not usages of ARFU.
> Replacing ARFU by Unsafe in BufferedInputStream makes the code more
> similar to the other usages of Unsafe in the JDK.
>
> [...]
>
> >
> > Paul.
> >
>
> Rémi
>
> * removing classes from a CDS archive is important for 32 bits windows VM
>
> Rémi
>


-- 
Sent from my phone

Re: RFR: jsr166 jdk9 integration wave 6

[Paul Sandoz]

Hi Martin,

miscellaneous
—

You reverted Aleksey’s change s/putOrderedObject/putObjectRelease.

The *Ordered* methods are now removed from the “real” jdk.internal.misc.Unsafe.

Paul.


> On 3 Apr 2016, at 20:29, Martin Buchholz  wrote:
> 
> Easy changes to review, up to April Fools day, in part to make room
> for later unfinished more exciting changes.
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Remi Forax]

- Mail original -
> De: "Paul Sandoz" 
> Cc: "core-libs-dev Libs" 
> Envoyé: Mercredi 6 Avril 2016 12:37:50
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of  
> AtomicReferenceFieldUpdater with Unsafe
> 
> 
> > On 6 Apr 2016, at 12:10, Remi Forax  wrote:
> > 
> > - Mail original -
> >> De: "Paul Sandoz" 
> >> Cc: "core-libs-dev Libs" 
> >> Envoyé: Mercredi 6 Avril 2016 09:37:00
> >> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of
> >>AtomicReferenceFieldUpdater with Unsafe
> >> 
> >> 
> >>> On 5 Apr 2016, at 17:15, Claes Redestad 
> >>> wrote:
> >>> 
> >>> On 04/04/2016 05:45 PM, Martin Buchholz wrote:
> > I think this one is going too far.
> > 
> > A*FU/VarHandles should are supposed to act like a go-to replacement for
> > Unsafe throughout the class library, and we want to shrink the Unsafe
> > exposure. Also, I don't think removing A*FU in favor of Unsafe here
> > wins
> > us anything: there should be no throughput hit, and we *will* load A*FU
> > down the road anyway, negating the startup wins.
> >> 
> >> +1 i would leave this one as is.
> >> 
> >> In general same goes for the @Stable/ForceInline annotations etc. We
> >> should
> >> use this stuff carefully within java.base and also sparingly to qualifying
> >> JDK modules.
> > 
> > While i fully agree in the general case, in disagree for this specific
> > case,
> > there are few uses of ARFU inside the JDK (or outside) but currently
> > because BufferedInputStream uses an ARFU, each time someone starts a Java
> > application, the VM loads ARFU and its implementation with a high
> > probability to no need it at all after
> > 
> 
> Does that really contribute sufficiently to slow down in start time? It
> really seems like a micro-optimisation.

small streams become big rivers (i don't know the idiomatic sentence in 
English, so it's a rough translation from a French idiom),
currently the main problem is that the loading of modules adds so much overhead 
to the startup time that you see nothing :(

Also, startup time is one aspect, size of the VM data structures at runtime, 
size of the CDS archive* are also impacted.

> 
> 
> > ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage
> > of Unsafe for a good reason goes in the right direction here,
> > when VarHandle will replace usages of Unsafe, the code of
> > BufferedInputStream will be refactored again.
> > 
> 
> My preference is not to change it if it’s gonna change later on.

but there is also a good chance to miss that change later because you will look 
for usages of Unsafe and not usages of ARFU.
Replacing ARFU by Unsafe in BufferedInputStream makes the code more similar to 
the other usages of Unsafe in the JDK.

[...]

> 
> Paul.
> 

Rémi

* removing classes from a CDS archive is important for 32 bits windows VM

Rémi

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Paul Sandoz]

Hi Steve,

My feeling is it’s too premature to introduce a general Memory (region) 
allocation interface at this moment. What is currently specified can be 
supported using:

  IntFunction

But i don’t wanna discourage you! this thread has raised some interesting 
points.

Project Panama is gonna take a swing at defining a more general notion of a 
memory region and the Arrays 2.0 work should support indexes greater than 
Integer.MAX_VALUE.

In this respect I think we should hold off doing anything premature for Java 9 
(feature freeze is getting closer), and i encourage you to participate on the 
Panama lists.


—

Here is some context some of which you probably know and some which you might 
not:

- ByteBuffer constructors are deliberately package scoped, as there are some 
intricate dependencies between the implementations and we want control over who 
can implement. Any new form of allocation will require changes here (package 
scoped or otherwise).

- current ByteBuffer implementations are either backed by a byte[] (managed or 
non-direct) or an off-heap allocated (direct) region. At the moment access to 
both those regions go through separate code paths, but they could be unified 
using the Unsafe double addressing mode, which should greatly simplify the 
implementations. I have started making some small steps towards that 
(JDK-8149469 and JDK-8151163). Even these small steps require careful analysis 
to evaluate performance across multiple platforms.

- VarHandles leverages the Unsafe double addressing mode to support enhanced 
atomic access to heap or direct ByteBuffers [1], thus the same code is used in 
both kinds of buffer.


—

I am not sure what plans you have for buffer implementations themselves.

How do you propose to allocate a ByteBuffer instance that covers a region of 3D 
XPoint memory?

Would it be similar to that of direct buffers, e.g. a variation of 
DirectByteBuffer, but with different factory constructor code to allocate the 
memory region within the XPoint memory system and assign the buffer base 
address to the start of that allocated region?

Thanks,
Paul.

[1] 
http://cr.openjdk.java.net/~psandoz/jdk9/varhandles/specdiff/java/lang/invoke/MethodHandles-report.html#method:byteBufferViewVarHandle(java.lang.Class,
 boolean)


> On 6 Apr 2016, at 03:49, Dohrmann, Steve  wrote:
> 
> Re: JDK-8153111
> 
> 
> Hi,
> 
> Below are responses to some of the points brought up in the discussion as 
> well as is a little expansion of the reasoning that went into the proposed 
> API.
> 
> One motivation we saw for doing anything beyond a concrete ByteBuffer class 
> was application code (e.g. Cassandra) that allocates many off-heap 
> ByteBuffers using ByteBuffer#allocateDirect.  We reasoned that if the 
> allocation of ByteBuffers could be done using a common memory interface then 
> only the code that provisioned instances of the the memory spaces would have 
> to change in order to switch or mix memory types.
> 
> We did think of overloading the ByteBuffer#allocateDirect method with memory 
> space info and avoid an allocation interface.  We ended up with a separate 
> user called interface scheme because we imagined that extensions of the 
> memory interface would enable new memory functionality that required new 
> methods (e.g. memory transactions for persistence).  Without a separate 
> callable interface, the static method space in ByteBuffer might have to 
> change again.
> 
> For any API In general we saw the need for two things 1) something to 
> represent a memory space from which objects are allocated (a Memory instance) 
> and 2) a broadly usable familiar "anchor" type as the common data object 
> (java.nio.ByteBuffer).
> 
> The two points for extension with the current proposal are: 1) Constructors 
> on Memory implementation classes -- allow implementors the ability to offer 
> features on the memory space itself (e.g. partitioning, size limits) and 2) 
> future extensions on the Memory interface -- for example PersistentMemory.
> 
> Regarding a more elaborate scheme for memory space creation -- we did 
> consider a factory scheme for memory object allocation but could not get 
> comfortable with either a) standardized method signatures suitable for 
> various kinds of memory or b) the complexity that something like a 
> general-purpose "spec" format would add, even if we could come up with it.  
> Direct construction does expose more to the user but it seems sufficient and 
> might be the best given what we can say about the future of heterogeneous 
> memory at this point.
> 
> Regarding the suggested addition of keyed access to ByteBuffers, we are 
> assuming this is only proposed to enable sharing?  We thought it might take a 
> while to properly explore the details (i.e. semantics / thread safety / 
> predicable performance) of sharing such that it would work well and maybe 
> even extend well to 

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Paul Sandoz]

> On 6 Apr 2016, at 12:10, Remi Forax  wrote:
> 
> - Mail original -
>> De: "Paul Sandoz" 
>> Cc: "core-libs-dev Libs" 
>> Envoyé: Mercredi 6 Avril 2016 09:37:00
>> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of 
>> AtomicReferenceFieldUpdater with Unsafe
>> 
>> 
>>> On 5 Apr 2016, at 17:15, Claes Redestad  wrote:
>>> 
>>> On 04/04/2016 05:45 PM, Martin Buchholz wrote:
> I think this one is going too far.
> 
> A*FU/VarHandles should are supposed to act like a go-to replacement for
> Unsafe throughout the class library, and we want to shrink the Unsafe
> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins
> us anything: there should be no throughput hit, and we *will* load A*FU
> down the road anyway, negating the startup wins.
>> 
>> +1 i would leave this one as is.
>> 
>> In general same goes for the @Stable/ForceInline annotations etc. We should
>> use this stuff carefully within java.base and also sparingly to qualifying
>> JDK modules.
> 
> While i fully agree in the general case, in disagree for this specific case,
> there are few uses of ARFU inside the JDK (or outside) but currently because 
> BufferedInputStream uses an ARFU, each time someone starts a Java 
> application, the VM loads ARFU and its implementation with a high probability 
> to no need it at all after
> 

Does that really contribute sufficiently to slow down in start time? It really 
seems like a micro-optimisation.


> ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage 
> of Unsafe for a good reason goes in the right direction here,
> when VarHandle will replace usages of Unsafe, the code of BufferedInputStream 
> will be refactored again.
> 

My preference is not to change it if it’s gonna change later on.


>> 
> 
> -Aleksey
 It is surprising to see new uses of Unsafe when we have an ongoing
 initiative within openjdk (especially from Paul Sandoz) to remove most
 uses.  Varhandles are coming and are expected to replace uses of
 Unsafe in the JDK.
>>> 
>>> This is just a very minor win on hello world/-version style tests, so I'm
>>> happy to withdraw this if other early usages, such as CHM, is moving to
>>> VarHandles anyhow.
>>> 
>>> OTOH using dangerous, internal APIs like this rather than nice, public APIs
>>> early in the VM bootstrap has other merits, such as not unintentionally
>>> causing bootstrap issues. Say, I don't know if VarHandles have any
>>> dependencies on java.lang.invoke currently…
>> 
>> It does, but was designed to be minimize bootstrap issues and class spinning
>> so there are less dependencies than MHs.
>> 
>> CHM is a tricky class because MethodType uses CHM and VHs uses MethodType.
>> There is probably a way of switching from a less concurrent concurrent map
>> to CHM at “safe-point” when the VM transitions to booted. To be
>> investigated...
> 
> another solution is perhaps to not use a concurrent hashmap in MethodType, 
> method types need to be interned only the first time a method handle is 
> invoked with an invokeExact/invoke (but not by invokedynamic) so instead of 
> interning all method types which artificially put pressure on the interning 
> map to be lock free, interning only the method type when need it may allow to 
> not use a CHM in MethodType.
> 

I need to re-familiarise myself with the code to see what is possible here. 
MethodType also comes with a shared erased form which also caches LambdaForms 
for various kinds. It’s not clear to me if this can be easily be teased apart.

Paul.

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Remi Forax]

- Mail original -
> De: "Paul Sandoz" 
> Cc: "core-libs-dev Libs" 
> Envoyé: Mercredi 6 Avril 2016 09:37:00
> Objet: Re: RFR: 8153334: Replace BufferedInputStreams use of  
> AtomicReferenceFieldUpdater with Unsafe
> 
> 
> > On 5 Apr 2016, at 17:15, Claes Redestad  wrote:
> > 
> > On 04/04/2016 05:45 PM, Martin Buchholz wrote:
> >>> I think this one is going too far.
> >>> 
> >>> A*FU/VarHandles should are supposed to act like a go-to replacement for
> >>> Unsafe throughout the class library, and we want to shrink the Unsafe
> >>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins
> >>> us anything: there should be no throughput hit, and we *will* load A*FU
> >>> down the road anyway, negating the startup wins.
> 
> +1 i would leave this one as is.
> 
> In general same goes for the @Stable/ForceInline annotations etc. We should
> use this stuff carefully within java.base and also sparingly to qualifying
> JDK modules.

While i fully agree in the general case, in disagree for this specific case,
there are few uses of ARFU inside the JDK (or outside) but currently because 
BufferedInputStream uses an ARFU, each time someone starts a Java application, 
the VM loads ARFU and its implementation with a high probability to no need it 
at all after

ARFU are not a replacement of Unsafe, VarHandles are. So adding a new usage of 
Unsafe for a good reason goes in the right direction here,
when VarHandle will replace usages of Unsafe, the code of BufferedInputStream 
will be refactored again.

> 
> >>> 
> >>> -Aleksey
> >> It is surprising to see new uses of Unsafe when we have an ongoing
> >> initiative within openjdk (especially from Paul Sandoz) to remove most
> >> uses.  Varhandles are coming and are expected to replace uses of
> >> Unsafe in the JDK.
> > 
> > This is just a very minor win on hello world/-version style tests, so I'm
> > happy to withdraw this if other early usages, such as CHM, is moving to
> > VarHandles anyhow.
> > 
> > OTOH using dangerous, internal APIs like this rather than nice, public APIs
> > early in the VM bootstrap has other merits, such as not unintentionally
> > causing bootstrap issues. Say, I don't know if VarHandles have any
> > dependencies on java.lang.invoke currently…
> 
> It does, but was designed to be minimize bootstrap issues and class spinning
> so there are less dependencies than MHs.
> 
> CHM is a tricky class because MethodType uses CHM and VHs uses MethodType.
> There is probably a way of switching from a less concurrent concurrent map
> to CHM at “safe-point” when the VM transitions to booted. To be
> investigated...

another solution is perhaps to not use a concurrent hashmap in MethodType, 
method types need to be interned only the first time a method handle is invoked 
with an invokeExact/invoke (but not by invokedynamic) so instead of interning 
all method types which artificially put pressure on the interning map to be 
lock free, interning only the method type when need it may allow to not use a 
CHM in MethodType.

> 
> Paul.
> 

Rémi

Re: RFR 8150829: Enhanced drop-args, identity and default constant, varargs adjustment

[Michael Haupt]

Hi Shilpi,

note this is not a *R*eview, but thumbs up, and I'll be happy to sponsor the 
push once a *R*eviewer agrees.

Best,

Michael

> Am 22.03.2016 um 12:41 schrieb shilpi.rast...@oracle.com:
> 
> Hi All,
> 
> Please review the following-
> 
> https://bugs.openjdk.java.net/browse/JDK-8150829
> http://cr.openjdk.java.net/~srastogi/8150829/webrev.04
> 
> 
> Thanks,
> Shilpi

-- 

 
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: JDK-8152622: tools/pack200/Pack200Props.java timed out

[Alan Bateman]

On 06/04/2016 04:47, Kumar Srinivasan wrote:

Hi,

I made some adjustments, based on private feedback.

New Webrev:
http://cr.openjdk.java.net/~ksrini/8152622/webrev.01/

Changes
 * Modified  ModuleAttributes  test to  use the new utility method,
   this also requires a way to filter/select  filename patterns.

* Use preVisitDirectory to create directories once, and ignore 
/packages directories.


Creating a zip file from the classes in the jrt file system make sense, 
and should be fast.


A few comments on Utils.JrtToZip:

- the URI creation in the run() method isn't reliable, could you use 
this instead:

  URI uri = URI.create("jar:" + outFile.toURI());

- In the toZipFs method then I assume you should use 
URI.create("jrt:/"), best to stay away from URL.


- Is Files.createDirectories needed? The walk is specified to be depth 
first so you'll also visit parent directories first.


- I'm also curious about the REPLACE_EXISTING as I assume that isn't needed.

A minor comment is that "root" rather than "p" would be nicer for the 
root directory. Personally I would avoid the really long lines as it 
makes future side-by-side reviews harder. Also throws Exception seems 
too broad but it's test code so not a big deal.


-Alan.

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

[Alan Bateman]

On 06/04/2016 08:59, Amy Lu wrote:

Yes :-)

Please review the updated patch: 
http://cr.openjdk.java.net/~amlu/8153563/webrev.01/


Thanks,
Amy

Looks fine.

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

[Amy Lu]

On 4/6/16 3:52 PM, Alan Bateman wrote:


On 06/04/2016 08:47, Amy Lu wrote:

:
  *
  * @build Basic
+ * @modules java.base/jdk.internal.misc
  * @run main CopyDirectMemory
  */


It might be clearer to put it before the @build, otherwise looks okay.

Yes :-)

Please review the updated patch: 
http://cr.openjdk.java.net/~amlu/8153563/webrev.01/


Thanks,
Amy


--- old/test/java/nio/Buffer/Basic.java 2016-04-06 15:57:56.0 +0800
+++ new/test/java/nio/Buffer/Basic.java 2016-04-06 15:57:56.0 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -27,6 +27,7 @@
  *  4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529
  *  6221101 6234263 6535542 6591971 6593946 6795561 7190219 7199551 8065556
  *  8149469
+ * @modules java.base/jdk.internal.misc
  * @author Mark Reinhold
  */
 
--- old/test/java/nio/Buffer/CopyDirectMemory.java	2016-04-06 15:57:57.0 +0800

+++ new/test/java/nio/Buffer/CopyDirectMemory.java  2016-04-06 
15:57:57.0 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2007, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -25,6 +25,7 @@
  * @summary Test view buffer bulk operations for large buffers.
  * @bug 4463011
  *
+ * @modules java.base/jdk.internal.misc
  * @build Basic
  * @run main CopyDirectMemory
  */

Re: JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

[Alan Bateman]

On 06/04/2016 08:47, Amy Lu wrote:

:
  *
  * @build Basic
+ * @modules java.base/jdk.internal.misc
  * @run main CopyDirectMemory
  */


It might be clearer to put it before the @build, otherwise looks okay.

-Alan

JDK 9 RFR of JDK-8153563: java/nio/Buffer/Basic.java and CopyDirectMemory.java are failing after JDK-8149469

[Amy Lu]

With test/java/nio/Buffer/BasicByte.java change in JDK-8149469, test

java/nio/Buffer/Basic.java
java/nio/Buffer/CopyDirectMemory.java

now requires
@modules java.base/jdk.internal.misc

Please review the patch.

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

Thanks,
Amy

--- old/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.0 +0800
+++ new/test/java/nio/Buffer/Basic.java 2016-04-06 15:39:19.0 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2000, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -27,6 +27,7 @@
  *  4526177 4463011 4660660 4661219 4663521 4782970 4804304 4938424 6231529
  *  6221101 6234263 6535542 6591971 6593946 6795561 7190219 7199551 8065556
  *  8149469
+ * @modules java.base/jdk.internal.misc
  * @author Mark Reinhold
  */
 
--- old/test/java/nio/Buffer/CopyDirectMemory.java	2016-04-06 15:39:20.0 +0800

+++ new/test/java/nio/Buffer/CopyDirectMemory.java  2016-04-06 
15:39:20.0 +0800
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2002, 2007, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2002, 2016, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -26,6 +26,7 @@
  * @bug 4463011
  *
  * @build Basic
+ * @modules java.base/jdk.internal.misc
  * @run main CopyDirectMemory
  */
 

Re: RFR: 8153334: Replace BufferedInputStreams use of AtomicReferenceFieldUpdater with Unsafe

[Paul Sandoz]

> On 5 Apr 2016, at 17:15, Claes Redestad  wrote:
> 
> On 04/04/2016 05:45 PM, Martin Buchholz wrote:
>>> I think this one is going too far.
>>> 
>>> A*FU/VarHandles should are supposed to act like a go-to replacement for
>>> Unsafe throughout the class library, and we want to shrink the Unsafe
>>> exposure. Also, I don't think removing A*FU in favor of Unsafe here wins
>>> us anything: there should be no throughput hit, and we *will* load A*FU
>>> down the road anyway, negating the startup wins.

+1 i would leave this one as is.

In general same goes for the @Stable/ForceInline annotations etc. We should use 
this stuff carefully within java.base and also sparingly to qualifying JDK 
modules.

>>> 
>>> -Aleksey
>> It is surprising to see new uses of Unsafe when we have an ongoing
>> initiative within openjdk (especially from Paul Sandoz) to remove most
>> uses.  Varhandles are coming and are expected to replace uses of
>> Unsafe in the JDK.
> 
> This is just a very minor win on hello world/-version style tests, so I'm 
> happy to withdraw this if other early usages, such as CHM, is moving to 
> VarHandles anyhow.
> 
> OTOH using dangerous, internal APIs like this rather than nice, public APIs 
> early in the VM bootstrap has other merits, such as not unintentionally 
> causing bootstrap issues. Say, I don't know if VarHandles have any 
> dependencies on java.lang.invoke currently…

It does, but was designed to be minimize bootstrap issues and class spinning so 
there are less dependencies than MHs.

CHM is a tricky class because MethodType uses CHM and VHs uses MethodType. 
There is probably a way of switching from a less concurrent concurrent map to 
CHM at “safe-point” when the VM transitions to booted. To be investigated...

Paul.

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

[Alan Bateman]

On 06/04/2016 06:14, Alejandro Murillo wrote:


I'd like to push the changeset below to exclude 
java/nio/Buffer/BasicByte.java
It started failing after the hotspot snapshot was pushed to jdk9/dev 
tonight.
https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for 
that failure.


Would it be possible to add @modules java.base/jdk.internal.misc, as 
below, and not exclude these tests?


-Alan


$ hg diff -g .
diff --git a/test/java/nio/Buffer/Basic.java 
b/test/java/nio/Buffer/Basic.java

--- a/test/java/nio/Buffer/Basic.java
+++ b/test/java/nio/Buffer/Basic.java
@@ -22,6 +22,7 @@
  */

 /* @test
+ * @modules java.base/jdk.internal.misc
  * @summary Unit test for buffers
  * @bug 4413135 4414911 4416536 4416562 4418782 4471053 4472779 
4490253 4523725
  *  4526177 4463011 4660660 4661219 4663521 4782970 4804304 
4938424 6231529
diff --git a/test/java/nio/Buffer/CopyDirectMemory.java 
b/test/java/nio/Buffer/CopyDirectMemory.java

--- a/test/java/nio/Buffer/CopyDirectMemory.java
+++ b/test/java/nio/Buffer/CopyDirectMemory.java
@@ -25,6 +25,7 @@
  * @summary Test view buffer bulk operations for large buffers.
  * @bug 4463011
  *
+ * @modules java.base/jdk.internal.misc
  * @build Basic
  * @run main CopyDirectMemory
  */

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

[Peter Levart]

Hi Roger,

On 04/05/2016 04:41 PM, Peter Levart wrote:

On 04/04/2016 11:50 PM, Roger Riggs wrote:
I don't see the need to change Cleaner to an interface to be able to 
provide
an additional method on CleanerImpl or a subclass and a factory 
method could

provide for a clean and very targeted interface to Bits/Direct buffer.


I would like this to be an instance method so it would naturally 
pertain to a particular Cleaner instance. Or it could be a static 
method that takes a Cleaner instance. One of my previous webrevs did 
have such method on the CleanerImpl, but I was advised to move it to 
Cleaner as a package-private method and expose it via SharedSecrets to 
internal code. I feel such "camouflage" is very awkward now that we 
have modules and other mechanisms exist. So I thought it would be most 
elegant to make Cleaner an interface so it can be extended with an 
internal interface to communicate intent in a type-safe and 
auto-discoverable way. The change to make it interface:


http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.part2.1.rev01/

...actually simplifies implementation (33 lines removed in total) and 
could be seen as an improvement in itself.


Are you afraid that if Cleaner was an interface, others would attempt 
to make implementations of it? Now that we have default methods on 
interfaces it is easy to compatibly extend the API even if it is an 
interface so that no 3rd party implementations are immediately broken. 
Are you thinking of security implications when some code is handed a 
Cleaner instance that it doesn't trust? I don't think there is a 
utility for Cleaner instances to be passed from untrusted to trusted 
code, do you?


...even if we don't do anything for DirectByteBuffer(s) in 
java.lang.ref.Cleaner and leave things as they stand (using 
jdk.internal.ref.Cleaner), I would still make this transition to 
interface to enable possible future internal extensions to 
java.lang.ref.Cleaner. As I said, this is a source compatible change, 
but not binary compatible, so if we do it, it must be performed before 
JDK 9 ships.


Regards, Peter

Re: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

[Bernd Eckenfels]

Hello Steve,

Thank you for addressing all concerns raised in the discussion.

For my points:

Using BufferSupplier or similar as the interface name can be mixed with 
class/constructor names which describe the actual type of memory. However yes I 
agree that “Memory” has the additional benefit that it can be used directly as 
a postfix in the class name, so thinking more about it, I agree with the nice 
and concrete “Memory” name.

I shortened the method to “allocate()”,  but you are right it might be better 
to make it a bit more specific if extensions are to be expected.

My main motivation behind a long key was, that in most scenarios which come to 
my mind (NVRAM, Flash, mmaped, shmem) the position of the allocated segment is 
relevant for cross VM (concurrent or sequential, as in the persisted case)  
sharing. As a ByteBuffer is not only a window into those memory segments but 
also a active datastructure (pos) it would be ugly to request only a single 
buffer to cover a large region. Especially with a 32bit size limit.

But yes it might also be possible to setup the position/sharing details with 
the Memory constructor request a large ByteBuffer and then split the actual 
buffers mapped on top of it (and do the allocation management based on start 
positions by hand)

The meaning of size in combination with the allocation key would be provider 
dependent. One option would be to refuse overlapping allocations but a more 
common implementation would simply allocate the segments (and if two VMs use 
overlapping regions they will exactly receive them). In all cases it should 
describe the capacity of the buffer.

Greetings
bernd
-- 
http://bernd.eckenfels.net

Von: Dohrmann, Steve
Gesendet: Mittwoch, 6. April 2016 03:59
An: core-libs-dev@openjdk.java.net
Betreff: JDK 9 proposal: allocating ByteBuffers on heterogeneous memory

Re: JDK-8153111


Hi,

Below are responses to some of the points brought up in the discussion as well 
as is a little expansion of the reasoning that went into the proposed API.

One motivation we saw for doing anything beyond a concrete ByteBuffer class was 
application code (e.g. Cassandra) that allocates many off-heap ByteBuffers 
using ByteBuffer#allocateDirect.  We reasoned that if the allocation of 
ByteBuffers could be done using a common memory interface then only the code 
that provisioned instances of the the memory spaces would have to change in 
order to switch or mix memory types.

We did think of overloading the ByteBuffer#allocateDirect method with memory 
space info and avoid an allocation interface.  We ended up with a separate user 
called interface scheme because we imagined that extensions of the memory 
interface would enable new memory functionality that required new methods (e.g. 
memory transactions for persistence).  Without a separate callable interface, 
the static method space in ByteBuffer might have to change again.

For any API In general we saw the need for two things 1) something to represent 
a memory space from which objects are allocated (a Memory instance) and 2) a 
broadly usable familiar "anchor" type as the common data object 
(java.nio.ByteBuffer).

The two points for extension with the current proposal are: 1) Constructors on 
Memory implementation classes -- allow implementors the ability to offer 
features on the memory space itself (e.g. partitioning, size limits) and 2) 
future extensions on the Memory interface -- for example PersistentMemory.

Regarding a more elaborate scheme for memory space creation -- we did consider 
a factory scheme for memory object allocation but could not get comfortable 
with either a) standardized method signatures suitable for various kinds of 
memory or b) the complexity that something like a general-purpose "spec" format 
would add, even if we could come up with it.  Direct construction does expose 
more to the user but it seems sufficient and might be the best given what we 
can say about the future of heterogeneous memory at this point.

Regarding the suggested addition of keyed access to ByteBuffers, we are 
assuming this is only proposed to enable sharing?  We thought it might take a 
while to properly explore the details (i.e. semantics / thread safety / 
predicable performance) of sharing such that it would work well and maybe even 
extend well to things like process-shared and cluster-shared ByteBuffers.  We 
elected to propose nothing for JDK 9 beyond what developers can already do with 
schemes based on e.g. ByteBuffer#duplicate.  We were thinking shared buffers 
could appear later, possibly as an extension of the Memory interface.   The 
keyed access scheme is simple and appealing, however.  One question: how is the 
request method's size parameter to be interpreted?

The suggestion of parameterizing the Memory interface bounded by ByteBuffers 
seems useful as it gives a clean way to support extended ByteBuffers.  Not sure 
if the change of the 

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

[Alejandro Murillo]

I didn't see that one  failing on my jprt sanity job
I went to check the code CopyDirectMemory.java, and it doesn't use 
jdk.internal.misc.Unsafe

(at least directly), so doesn't look like it's the same issue.
where did you see the failure ?


Alejandro


On 4/5/2016 11:59 PM, Amy Lu wrote:

java/nio/Buffer/CopyDirectMemory.java
run into the same issue, maybe it could be problem listed together in 
this patch?


Thanks,
Amy

On 4/6/16 1:14 PM, Alejandro Murillo wrote:


I'd like to push the changeset below to exclude 
java/nio/Buffer/BasicByte.java
It started failing after the hotspot snapshot was pushed to jdk9/dev 
tonight.
https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for 
that failure.


$ hg -R jdk9.dev/jdk tip -pv

changeset:   14082:5c98c9ad8ff2
tag: tip
user:amurillo
date:Tue Apr 05 22:06:15 2016 -0700
files:   test/ProblemList.txt
description:
8153564: Add java/nio/Buffer/BasicByte.java to exclude list until 
JDK-8153563 is fixed

Reviewed-by: tbd


diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt
--- a/test/ProblemList.txt  Tue Apr 05 20:02:21 2016 -0700
+++ b/test/ProblemList.txt  Tue Apr 05 22:06:15 2016 -0700
@@ -185,6 +185,8 @@

 java/nio/charset/coders/BashStreams.java 8149712 generic-all

+java/nio/Buffer/BasicByte.java 8153563 generic-all
+
  



 # jdk_rmi






--
Alejandro

Re: [9] RFR JDK-8153564: Add java/nio/Buffer/BasicByte.java to exclude list until JDK-8153563 is fixed

[Amy Lu]

java/nio/Buffer/CopyDirectMemory.java
run into the same issue, maybe it could be problem listed together in 
this patch?


Thanks,
Amy

On 4/6/16 1:14 PM, Alejandro Murillo wrote:


I'd like to push the changeset below to exclude 
java/nio/Buffer/BasicByte.java
It started failing after the hotspot snapshot was pushed to jdk9/dev 
tonight.
https://bugs.openjdk.java.net/browse/JDK-8153563 has been filed for 
that failure.


$ hg -R jdk9.dev/jdk tip -pv

changeset:   14082:5c98c9ad8ff2
tag: tip
user:amurillo
date:Tue Apr 05 22:06:15 2016 -0700
files:   test/ProblemList.txt
description:
8153564: Add java/nio/Buffer/BasicByte.java to exclude list until 
JDK-8153563 is fixed

Reviewed-by: tbd


diff -r 04f56d4ca167 -r 5c98c9ad8ff2 test/ProblemList.txt
--- a/test/ProblemList.txt  Tue Apr 05 20:02:21 2016 -0700
+++ b/test/ProblemList.txt  Tue Apr 05 22:06:15 2016 -0700
@@ -185,6 +185,8 @@

 java/nio/charset/coders/BashStreams.java 8149712 generic-all

+java/nio/Buffer/BasicByte.java 8153563 generic-all
+
  



 # jdk_rmi