Re: Is returning a value != '0' or '1' as jboolean from a JNI function legal?

[Krystal Mok]

Thanks Volker! I hadn't been following new development much and this is
great!
I just checked the latest HS sources [1] and my old code is still there.
I'll prepare a webrev to remove that workaround code.

Thanks,
Kris

[1]:
http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1/c1_Runtime1.cpp#l1380

On Mon, Aug 20, 2018 at 9:28 AM, Volker Simonis 
wrote:

> On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok 
> wrote:
> > Hi guys,
> >
> > Haha this is fun. I actually hit this issue the hard way and had to
> tweak a
> > bit of my code to accommodate that: I had to return a jint from a
> function
> > that I wanted to return a jbool at first:
> > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/
> 8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp
> >
>
> Interesting, but I think that mis-behavior should have been fixed
> meanwhile by the infamous "Better byte behavior" change [1] (which was
> a security fix, so you won't find too much information about it).
>
> So maybe you can remove your workaround and comment now :)
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72
>
> > - Kris
> >
> > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis  >
> > wrote:
> >>
> >> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev 
> >> wrote:
> >> > On 08/20/2018 12:22 PM, Volker Simonis wrote:
> >> >> So to summarize, my current view on this topic is:
> >> >>  - JNI functions returning a jboolean are only allowed to return
> >> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI
> spcification.
> >> >
> >> > Now *I* am having trouble seeing where exactly the JNI spec says the
> >> > domain of jboolean is
> >> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following
> >> > definition is provided for
> >> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the
> >> > domain, because those are
> >> > "convenience" defines. And "Description" in the table says jboolean is
> >> > "unsigned 8 bits", which
> >> > seems to invite interpretation that all 8 bits are usable.
> >> >
> >> > John says [2]:
> >> >
> >> > "The JNI documents specify that, at least for returning values from
> >> > native methods, a Java boolean
> >> > (T_BOOLEAN) value is converted to the value-set 0..1 by first
> truncating
> >> > to a byte (0..255 or maybe
> >> > -128..127) and then testing against zero."
> >> >
> >> > ...which is what I am looking for, but I cannot find the "JNI
> document"
> >> > that actually says that. I
> >> > can see the idea of that in JVMS [3], but that seems to only apply to
> >> > on-heap booleans, does that
> >> > also extend to jboolean's? Maybe John can point out the JNI document
> >> > where it is said explicitly?
> >> >
> >>
> >> Yes, you're right - there's no exact documentation for neither of the
> >> two possible interpretations. A colleague just pointed me to the
> >> definition of invokestatic in the JVMS [4] which has the following
> >> sentence:
> >>
> >> "If the native method returns a value, the return value of the
> >> platform-dependent code is converted in an implementation-dependent
> >> way to the return type of the native method and pushed onto the
> >> operand stack."
> >>
> >> But then again, it has this unfortunate "implementation-dependent"
> >> which can be interpreted either way :(
> >>
> >> [4]
> >> https://docs.oracle.com/javase/specs/jvms/se10/html/
> jvms-6.html#jvms-6.5.invokestatic
> >>
> >> >
> >> >>  - to code in Java_java_io_Console_echo() should be fixed (as
> >> >> confirmed by Sherman later in this thread)
> >> >
> >> > Yes, that's a bug waiting to happen anyway.
> >> >
> >> >
> >> >>  - normalization of native, off-heap 8-bit values to Java booleans as
> >> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is
> (1)
> >> >> only for convenience to simply access to off-heap data in Unsafe, (2)
> >> >> to implement better Java/Native integration in projects like Panama
> >> >> and (3) to fix legacy JNI code which was developed under the
> >> >> assumption that the advice in the "JNI Programmer's Guide &
> >> >> Specification" book is specification relevant.
> >> >
> >> > Yes, the intent seems to be what you describe. But see above about the
> >> > spec.
> >> >
> >> >
> >> > -Aleksey
> >> >
> >> > [1]
> >> > https://docs.oracle.com/javase/8/docs/technotes/
> guides/jni/spec/types.html#primitive_types
> >> > [2]
> >> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-
> dev/2016-August/024263.html
> >> > [3]
> >> > https://docs.oracle.com/javase/specs/jvms/se10/html/
> jvms-2.html#jvms-2.3.4
> >> >
>

Re: Is returning a value != '0' or '1' as jboolean from a JNI function legal?

[Krystal Mok]

Hi guys,

Haha this is fun. I actually hit this issue the hard way and had to tweak a
bit of my code to accommodate that: I had to return a jint from a function
that I wanted to return a jbool at first:
http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp

- Kris

On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis 
wrote:

> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev 
> wrote:
> > On 08/20/2018 12:22 PM, Volker Simonis wrote:
> >> So to summarize, my current view on this topic is:
> >>  - JNI functions returning a jboolean are only allowed to return
> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification.
> >
> > Now *I* am having trouble seeing where exactly the JNI spec says the
> domain of jboolean is
> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following
> definition is provided for
> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the
> domain, because those are
> > "convenience" defines. And "Description" in the table says jboolean is
> "unsigned 8 bits", which
> > seems to invite interpretation that all 8 bits are usable.
> >
> > John says [2]:
> >
> > "The JNI documents specify that, at least for returning values from
> native methods, a Java boolean
> > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating
> to a byte (0..255 or maybe
> > -128..127) and then testing against zero."
> >
> > ...which is what I am looking for, but I cannot find the "JNI document"
> that actually says that. I
> > can see the idea of that in JVMS [3], but that seems to only apply to
> on-heap booleans, does that
> > also extend to jboolean's? Maybe John can point out the JNI document
> where it is said explicitly?
> >
>
> Yes, you're right - there's no exact documentation for neither of the
> two possible interpretations. A colleague just pointed me to the
> definition of invokestatic in the JVMS [4] which has the following
> sentence:
>
> "If the native method returns a value, the return value of the
> platform-dependent code is converted in an implementation-dependent
> way to the return type of the native method and pushed onto the
> operand stack."
>
> But then again, it has this unfortunate "implementation-dependent"
> which can be interpreted either way :(
>
> [4]
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic
>
> >
> >>  - to code in Java_java_io_Console_echo() should be fixed (as
> >> confirmed by Sherman later in this thread)
> >
> > Yes, that's a bug waiting to happen anyway.
> >
> >
> >>  - normalization of native, off-heap 8-bit values to Java booleans as
> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1)
> >> only for convenience to simply access to off-heap data in Unsafe, (2)
> >> to implement better Java/Native integration in projects like Panama
> >> and (3) to fix legacy JNI code which was developed under the
> >> assumption that the advice in the "JNI Programmer's Guide &
> >> Specification" book is specification relevant.
> >
> > Yes, the intent seems to be what you describe. But see above about the
> spec.
> >
> >
> > -Aleksey
> >
> > [1]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types
> > [2]
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html
> > [3]
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4
> >
>

Race condition when serializing SerializedRandomAccessList

[Krystal Mok]

Hi core-libs,

I'd like to report a bug on race condition while serializing
SerializedRandomAccessList / deserializing SerializedList. This seems to be
a long standing bug, we've hit it on JDK8 and the same code is still there
in JDK11's core-lib.

In SerializedRandomAccessList.writeReplace(): [1]

private Object writeReplace() {
return new SynchronizedList<>(list);
}

Here, it's creating a new "face" of the current SerializedRandomAccessList,
but not passing down this.mutex into the newly created SynchronizedList.
What we've seen go wrong was that one thread was still appending to the
SerializedRandomAccessList, while another thread is trying to serialize it,
a ConcurrentModificationException may be thrown on the underlying list.

I've filed JDK-8208779 [2] to track this issue.

Note: this issue was reported by my colleague Shixiong Zhu at Databricks.
I'm just delegating the report to the core-libs list.
One past occurrence of the same issue can be found in Apache Spark in [3].

Thanks,
Kris

[1]:
http://hg.openjdk.java.net/jdk/jdk11/file/4322ef0c1684/src/java.base/share/classes/java/util/Collections.java#l2521
[2]: https://bugs.openjdk.java.net/browse/JDK-8208779
[3]:
https://issues.apache.org/jira/browse/SPARK-17463?focusedCommentId=15787809=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-15787809

Re: Oracle Java 8u161 regression in XML Schema Factory

[Krystal Mok]

Thanks Sean. It's more likely a JDK issue because my coworker simply
swapped the JAVA_HOME from 8u161 which failed with that error to 8u151 and
it worked fine.

I'll ask if he's got the cycles to distill a reproducer. If he does I'll
open a JBS ticket.

Thanks,
Kris

On Fri, Jan 26, 2018 at 12:06 AM, Seán Coffey <sean.cof...@oracle.com>
wrote:

> I don't see them being related with data given below. Maybe there's a
> classpath configuration issue ?
>
> If you feel there's a bug in the JDK libraries, please report it via
> https://bugs.java.com/
>
> regards,
> Sean.
> On 26/01/2018 00:23, Krystal Mok wrote:
>
> Hi guys,
>
> A coworker of mine had hit this issue last night on 8u161 and it worked
> fine on 8u151:
>
> ERROR: /home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/
> external/jackson_datatype_joda_shaded/BUILD:5:1: Building
> external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar
> (35 source files) failed (Exit 1)
> java.lang.InternalError: Cannot find requested resource bundle for locale
> en_US
> at com.sun.tools.javac.util.JavacMessages.getBundles(
> JavacMessages.java:128)
> at com.sun.tools.javac.util.JavacMessages.getLocalizedString(
> JavacMessages.java:147)
> at com.sun.tools.javac.util.JavacMessages.getLocalizedString(
> JavacMessages.java:140)
> at com.sun.tools.javac.util.Log.localize(Log.java:788)
> at com.sun.tools.javac.util.Log.printLines(Log.java:586)
> at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(
> JavacTaskImpl.java:170)
> at com.sun.tools.javac.api.JavacTaskImpl.doCall(
> JavacTaskImpl.java:96)
> at com.sun.tools.javac.api.JavacTaskImpl.call(
> JavacTaskImpl.java:90)
> at com.google.devtools.build.buildjar.javac.BlazeJavacMain.
> compile(BlazeJavacMain.java:105)
> at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.
> invokeJavac(SimpleJavaLibraryBuilder.java:106)
> at com.google.devtools.build.buildjar.
> ReducedClasspathJavaLibraryBuilder.compileSources(
> ReducedClasspathJavaLibraryBuilder.java:53)
> at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.
> compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
> at com.google.devtools.build.buildjar.
> SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> processRequest(BazelJavaBuilder.java:105)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> runPersistentWorker(BazelJavaBuilder.java:67)
> at com.google.devtools.build.buildjar.BazelJavaBuilder.
> main(BazelJavaBuilder.java:45)
> Caused by: java.util.MissingResourceException: Can't find bundle for base
> name com.google.errorprone.errors, locale en_US
> at java.util.ResourceBundle.throwMissingResourceException(
> ResourceBundle.java:1573)
> at java.util.ResourceBundle.getBundleImpl(ResourceBundle.
> java:1396)
> at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
> at com.sun.tools.javac.util.JavacMessages.lambda$add$0(
> JavacMessages.java:106)
> at com.sun.tools.javac.util.JavacMessages.getBundles(
> JavacMessages.java:125)
> ... 15 more
>
> Resource bundle loading issue...could that be related to this XML issue
> here?
>
> Thanks,
> Kris
>
> On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey <sean.cof...@oracle.com>
> wrote:
>
>> On 25/01/2018 11:58, Bernd wrote:
>>
>> Hello,
>>>
>>> some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
>>> u162) but work with 8u152.
>>>
>>> I cant reproduce the fault in a stand-alone program so it seems to be
>>> related to classloader/reflection magic of those tools, sorry.
>>>
>>> Is this a regression of 8159240
>>> <http://bugs.java.com/view_bug.do?bug_id=JDK-8159240> (not public?)
>>>
>> Fixes in the CPU releases are kept private - hence the above bug is not
>> public. The changesets do become public once the release is made public
>> though. See : http://hg.openjdk.java.net/jdk
>> 8u/jdk8u/jaxws/rev/06086cb6c349
>>
>> I don't think it's a factor for what you're seeing.
>>
>> Classes nearer to those below were touched via JDK-8186080: Transform XML
>> interfaces
>> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cb84156d54b2
>> http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/08a44c164993
>>
>> This may be connected with some tools trying to redefine the classes
>> perhaps. Needs more investigating. Perhaps the XM

Re: Oracle Java 8u161 regression in XML Schema Factory

[Krystal Mok]

Hi guys,

A coworker of mine had hit this issue last night on 8u161 and it worked
fine on 8u151:

ERROR: 
/home/myuser/.cache/bazel/_bazel_myuser/some_hash_code/external/jackson_datatype_joda_shaded/BUILD:5:1:
Building
external/jackson_datatype_joda_shaded/libjackson-datatype-joda-class.jar
(35 source files) failed (Exit 1)
java.lang.InternalError: Cannot find requested resource bundle for locale
en_US
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:128)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:147)
at
com.sun.tools.javac.util.JavacMessages.getLocalizedString(JavacMessages.java:140)
at com.sun.tools.javac.util.Log.localize(Log.java:788)
at com.sun.tools.javac.util.Log.printLines(Log.java:586)
at
com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:170)
at
com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
at
com.google.devtools.build.buildjar.javac.BlazeJavacMain.compile(BlazeJavacMain.java:105)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder$1.invokeJavac(SimpleJavaLibraryBuilder.java:106)
at
com.google.devtools.build.buildjar.ReducedClasspathJavaLibraryBuilder.compileSources(ReducedClasspathJavaLibraryBuilder.java:53)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:109)
at
com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
at
com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)
Caused by: java.util.MissingResourceException: Can't find bundle for base
name com.google.errorprone.errors, locale en_US
at
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1573)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1396)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:854)
at
com.sun.tools.javac.util.JavacMessages.lambda$add$0(JavacMessages.java:106)
at
com.sun.tools.javac.util.JavacMessages.getBundles(JavacMessages.java:125)
... 15 more

Resource bundle loading issue...could that be related to this XML issue
here?

Thanks,
Kris

On Thu, Jan 25, 2018 at 8:41 AM, Seán Coffey  wrote:

> On 25/01/2018 11:58, Bernd wrote:
>
> Hello,
>>
>> some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and
>> u162) but work with 8u152.
>>
>> I cant reproduce the fault in a stand-alone program so it seems to be
>> related to classloader/reflection magic of those tools, sorry.
>>
>> Is this a regression of 8159240
>>  (not public?)
>>
> Fixes in the CPU releases are kept private - hence the above bug is not
> public. The changesets do become public once the release is made public
> though. See : http://hg.openjdk.java.net/jdk8u/jdk8u/jaxws/rev/06086cb6c34
> 9
>
> I don't think it's a factor for what you're seeing.
>
> Classes nearer to those below were touched via JDK-8186080: Transform XML
> interfaces
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cb84156d54b2
> http://hg.openjdk.java.net/jdk8u/jdk8u/jaxp/rev/08a44c164993
>
> This may be connected with some tools trying to redefine the classes
> perhaps. Needs more investigating. Perhaps the XMLSchemaLoader changes are
> a factor ?
>
> regards,
> Sean.
>
>
>> Here is the stacktrace anyway:
>>
>> com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema
>> factory class
>> com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does
>> not
>> extend from SchemaDVFactory.
>>  at
>> com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
>> getInstance(SchemaDVFactory.java:75)
>>  at
>> com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.
>> getInstance(SchemaDVFactory.java:57)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> reset(XMLSchemaLoader.java:1024)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> loadGrammar(XMLSchemaLoader.java:556)
>>  at
>> com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.
>> loadGrammar(XMLSchemaLoader.java:535)
>>  at
>> com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchema
>> Factory.newSchema(XMLSchemaFactory.java:254)
>>  at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
>> java:638)
>>  at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.
>> java:654)
>>  at
>> com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchema
>> Validator(BuilderTestHelper.java:57)
>>

Re: [PATCH] Inefficient ArrayList.subList().toArray()

[Krystal Mok]

Hi Sergey,

Not a Reviewer but I like this patch a lot. Thanks for contributing it to
OpenJDK!

Best regards,
Kris

On Thu, Jan 25, 2018 at 2:02 PM, Сергей Цыпанов 
wrote:

> Hi,
>
> I've run into poor performance of toArray() method called on result of
> subList() taken from java.util.ArrayList.
>
> Consider simple benchmark:
>
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-XX:+UseParallelGC", "-Xms1g", "-Xmx1g"})
> public class SubListToArrayBenchmark {
>
> @Benchmark
> public Integer[] list_typeChecked(Data holder) {
> return holder.list.toArray(new Integer[0]);
> }
>
> @Benchmark
> public Integer[] subList_typeChecked(Data holder) {
> return holder.list.subList(0, holder.size).toArray(new Integer[0]);
> }
>
> @State(Scope.Thread)
> public static class Data {
> ArrayList list;
>
> @Param({"0", "10", "100", "1000"})
> int size;
>
> @Setup
> public void setup() {
> list = IntStream
> .range(0, size)
> .boxed()
> .collect(toCollection(ArrayList::new));
> }
> }
> }
>
>
> With Java 1.8.0_162 on my PC (Intel i5-4690 3,5 GHz) it yields these
> results:
>
> Benchmark(size)  Mode  Cnt Score Error  Units
> list_typeChecked 0  avgt   504,630 ±0,062
> ns/op
> list_typeChecked   10  avgt   50  16,629 ±0,140  ns/op
> list_typeChecked 100  avgt   50  79,783 ±1,676  ns/op
> list_typeChecked   1000  avgt   50742,757 ±  10,357  ns/op
>
> subList_typeChecked  0  avgt   50  11,833 ±0,801  ns/op
> subList_typeChecked10  avgt   50  42,713 ±0,590  ns/op
> subList_typeChecked  100  avgt   50197,336 ±3,560  ns/op
> subList_typeChecked1000  avgt   50  1765,187 ±  19,729  ns/op
>
> With Java 9 subList performs slightly better but still much worse than
> list.
>
>
> Despite the fact that amount of data transfered from list to array is the
> same for both methods there's a huge difference in absolute values.
>
> Instantiation of SubList costs in average only 9.591 ± 0.650  ns and is
> independent on the size of its source so it couldn't be root cause.
>
> Here SubLists taken from ArrayList calls AbstractCollection.toArray()
> method while implementing RandomAccess and being array-based by its nature.
> Array-based ArrayList provides efficient implementation of toArray(T[])
> and we can apply the same approach for ArrayList.SubList.
>
> Here's the patch for JDK 9:
>
> 
> 
> 
>
> diff --git a/src/java.base/share/classes/java/util/ArrayList.java
> b/src/java.base/share/classes/java/util/ArrayList.java
> --- a/src/java.base/share/classes/java/util/ArrayList.java
> +++ b/src/java.base/share/classes/java/util/ArrayList.java
> @@ -1363,6 +1363,20 @@
>  }
>  };
>  }
> +
> +public Object[] toArray() {
> +return Arrays.copyOfRange(root.elementData, offset, size);
> +}
> +
> +@SuppressWarnings("unchecked")
> +public  T[] toArray(T[] a) {
> +if (a.length < size)
> +return (T[]) Arrays.copyOfRange(root.elementData,
> offset, size, a.getClass());
> +System.arraycopy(root.elementData, offset, a, 0, size);
> +if (a.length > size)
> +a[size] = null;
> +return a;
> +}
>  }
>
>  /**
>
> 
> 
> 
>
> Best regards,
> Sergey Tsypanov
>

Re: RFR: 8166840: Synthetic bridge constructor in ArrayList$Itr blocks inlining

[Krystal Mok]

Hi Claes,

For this particular case, this JDK-side change looks good to me.

Let me post out the HotSpot version of the change and let you guys decide
whether or not you guys want to take that version (which will take care of
the ArrayList$1 case without the JDK-side change).

Thanks,
Kris

On Wed, Sep 28, 2016 at 4:48 AM, Claes Redestad 
wrote:

> Hi,
>
> as discussed recently on hotspot-compiler-dev[1], having a private class
> with no default constructor can lead to C2 failing to inline, due to the
> synthetic bridge constructor using a dummy argument of an uninitialized
> class. This is really a problem in C2, as well as something which could
> ultimately be resolved by nestmates...
>
> However, there is an easy workaround in adding an empty package-private
> constructor. In the most recently found case - a microbenchmark stressing
> MethodHandles.iteratedLoop - adding this to ArrayList$Itr lead to a 2.5-3x
> speedup.
>
> This is me asking nicely to do a quick-fix for this in
> java.util.ArrayList$Itr now:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166840
> Webrev: http://cr.openjdk.java.net/~redestad/8166840/webrev.01/
>
> Thanks!
>
> /Claes
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/
> 2016-September/024407.html
>

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Krystal Mok]

Hi OpenJDK developers,

Replying on behalf of Azul Systems:

java.lang.Compiler is an integral part of the current Java SE spec, and is
currently being used by multiple independent Java SE implementations of
that spec in a spec-conforming way (Azul Zing, Azul Vega, and IBM J9 being
concrete exampleS). Before deprecation, a proposed replacement for Java SE
9 would need to be vetted to make sure that is satisfies the needs of
current implementations. While JEP165 is a start in that direction, it
appears to be very HotSpot specific, and is not written in a specification
form (e.g. there is no "If no compiler is available, these methods do
nothing." mention).

For example, Azul Zing’s ReadyNow feature makes use of the
java.lang.Compiler API to allow applications to pass directives down to the
VM, in a similar spirit to what IBM J9 does with the API. We continuously
evolve and enrich the commands we support in the API, e.g. in the “Object
command(Object)” method, and it would be potentially problematic for us to
lose the current API without having a flexible replacement in the Java SE
spec.

As such, we suggest that for the time being, java.lang.Compiler should be
neither depracated nor removed in Java SE 9. As a practical spec'ed
replacement is proposed that will cover the needs of implementations
currently using java.lang.Compiler, this can change. Perhaps in the Java SE
10 timeframe.

Thanks,
Kris (OpenJDK username: kmo)

On Wed, Sep 7, 2016 at 1:52 PM, Stuart Marks 
wrote:

> Hi all,
>
> Please review this small patch to deprecate java.lang.Compiler for removal.
>
> Thanks,
>
> s'marks
>
> # HG changeset patch
> # User smarks
> # Date 1473281459 25200
> #  Wed Sep 07 13:50:59 2016 -0700
> # Node ID e520c4e6970c079573bad20c6b1eba8d5794b34d
> # Parent  76ba1b74f268f1acc4847e242a2cfcd29880418c
> 4285505: deprecate java.lang.Compiler
> Reviewed-by: XXX
>
> diff -r 76ba1b74f268 -r e520c4e6970c src/java.base/share/classes/ja
> va/lang/Compiler.java
> --- a/src/java.base/share/classes/java/lang/Compiler.java   Tue Sep
> 06 16:08:54 2016 -0700
> +++ b/src/java.base/share/classes/java/lang/Compiler.java   Wed Sep
> 07 13:50:59 2016 -0700
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1995, 2014, Oracle and/or its affiliates. All rights
> reserved.
> + * Copyright (c) 1995, 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
> @@ -29,21 +29,18 @@
>   * The {@code Compiler} class is provided to support Java-to-native-code
>   * compilers and related services. By design, the {@code Compiler} class
> does
>   * nothing; it serves as a placeholder for a JIT compiler implementation.
> + * If no compiler is available, these methods do nothing.
>   *
> - *  When the Java Virtual Machine first starts, it determines if the
> system
> - * property {@code java.compiler} exists. (System properties are
> accessible
> - * through {@link System#getProperty(String)} and {@link
> - * System#getProperty(String, String)}.  If so, it is assumed to be the
> name of
> - * a library (with a platform-dependent exact location and type); {@link
> - * System#loadLibrary} is called to load that library. If this loading
> - * succeeds, the function named {@code java_lang_Compiler_start()} in that
> - * library is called.
> - *
> - *  If no compiler is available, these methods do nothing.
> + * @deprecated JIT compilers and their technologies vary too widely to
> + * be controlled effectively by a standardized interface. As such, many
> + * JIT compiler implementations ignore this interface, and are instead
> + * controllable by implementation-specific mechanisms such as command-line
> + * options. This class is subject to removal in a future version of Java
> SE.
>   *
>   * @author  Frank Yellin
>   * @since   1.0
>   */
> +@Deprecated(since="9", forRemoval=true)
>  public final class Compiler  {
>  private Compiler() {}   // don't make instances
>
>

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Krystal Mok]

Hi Tim,

Thanks for your reply. It's good to know at least the known use cases from
IBM have indeed been discussed.

On Thu, Sep 8, 2016 at 9:01 AM, Tim Ellison <t.p.elli...@gmail.com> wrote:

> On 07/09/16 23:45, Krystal Mok wrote:
> > I see that on the JBS page, your most recent comment says it's been
> decided
> > that for JDK9 it's okay to deprecate and forRemoval=true, while also
> > mentioning the uses of this class in IBM's implementation.
> >
> > Does that mean IBM has agreed on the deprecation of this class?
>
> Yep, I've seen those references and am ok with the deprecation in JDK9.
>
> > I thought J9 had features that allowed Java applications to do
> > fine-grained control over the JIT compiler at runtime, e.g. force
> > compilation of specified methods *at some certain point* in the
> > program.
>
> Not sure what you are thinking of there Kris.  We do implement the five
> public methods on Compiler to do pretty much what you would expect:
>
> java.lang.Compiler.command(Object any) - this only does something for a
> couple of custom arguments, most objects passed to it are simply ignored.
>
> java.lang.Compiler.compileClass(Class clazz) - the JIT will compile
> all methods in the given class. These compilations are synchronous, i.e.
> the application thread that called the API will wait until all
> compilations are finished.
>
> This and the next one are the ones I was talking about: these calls can be
made at arbitrary points in time during Java program execution, so they are
"dynamic".
For instance, I may have a program that wishes to convey phase shift
properties to the VM, by calling once of these methods right before the
phase shift happens. That's something a static configuration means (e.g.
compiler configuration file) won't be able to do. Ditto for the
"waitOnCompilationQueue" command.

Thanks,
Kris


> java.lang.Compiler.compileClasses(String s) - the JIT will compile all
> methods from classes that match the given string.
>
> java.lang.Compiler.disable() - disables all future JIT compilations.
>
> java.lang.Compiler.enable() - resumes JIT compilations.
>
> IMO dropping these APIs would not be a great loss.
>
> > What JEP 165 is proposing can only statically configure JIT behaviors for
> > HotSpot. The same approach doesn't seem to cover what J9 used to support.
> >
> > Could you please share more background on the discussions that led to the
> > decision?
>
> As you would expect, IBM and Oracle talk regularly about all things
> Java, and this topic was raised as a heads-up that it was coming to
> OpenJDK.  So there really isn't any background to the discussion.
>
> Regards,
> Tim
> (IBM Java team)
>
> > On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks <stuart.ma...@oracle.com>
> > wrote:
> >
> >> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
> >>
> >> :-)
> >>
> >>
> >> On 9/7/16 2:44 PM, Remi Forax wrote:
> >>
> >>> Yes, i like this patch :)
> >>>
> >>> Aleksey, It's worst than what you think because for a lot of people
> >>> Compiler == java compiler and not JIT compiler so they try to compile a
> >>> .java file with the method compileClasses(String).
> >>>
> >>> I'm glad this class will disappear soon.
> >>>
> >>> Rémi
> >>>
> >>> - Mail original -
> >>>
> >>>> De: "Aleksey Shipilev" <aship...@redhat.com>
> >>>> À: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev" <
> >>>> core-libs-dev@openjdk.java.net>
> >>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
> >>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
> >>>>
> >>>
> >>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
> >>>>
> >>>>> Please review this small patch to deprecate java.lang.Compiler for
> >>>>> removal.
> >>>>>
> >>>>
> >>>> Yes, +1.
> >>>> This class is very confusing to have these days.
> >>>>
> >>>> -Aleksey
> >>>>
> >>>
>

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Krystal Mok]

Hi Stuart,

Thanks for your reply. Indeed, the class doesn't really fit into the modern
world as it is now, for its original intended purpose. So, for its original
intent of configuring and controlling the JIT compiler(s), I'm more than
happy about the deprecation.

There are a couple of scenarios that I know of that make uses of the
java.lang.Compiler class as a generic entry point into the VM, not related
to the original intent at all. Let me think a bit about how to phrase those
scenarios correctly and update in a follow-up reply.

Thanks,
Kris

On Wed, Sep 7, 2016 at 4:42 PM, Stuart Marks <stuart.ma...@oracle.com>
wrote:

> Hi Kris,
>
> Well, there's not much background. We did contact IBM in regard to the
> mentions of java.lang.Compiler from their product pages, and they were OK
> with deprecating the API for removal. I can't speak to what impact this
> might have on IBM's products.
>
> I don't know much about JEP 165 [1] but it does appear to be able to
> update compiler directives at runtime. It doesn't seem to match the
> semantics of java.lang.Compiler. On the other hand, j.l.Compiler was
> introduced in the JDK 1.0 time frame, before production Java JIT compilers
> were delivered, so it's unlikely that its semantics match the needs of a
> modern JIT implementation.
>
> I really don't think anything is being lost by the deprecation and
> eventual removal of java.lang.Compiler. If anything, it's an improvement,
> as Rémi noted, since people will no longer confuse it with an API for
> invoking javac.
>
> s'marks
>
> [1] http://openjdk.java.net/jeps/165
>
> On 9/7/16 3:45 PM, Krystal Mok wrote:
>
> Hi Stuart,
>
> I see that on the JBS page, your most recent comment says it's been
> decided that for JDK9 it's okay to deprecate and forRemoval=true, while
> also mentioning the uses of this class in IBM's implementation.
>
> Does that mean IBM has agreed on the deprecation of this class? I thought
> J9 had features that allowed Java applications to do fine-grained control
> over the JIT compiler at runtime, e.g. force compilation of specified
> methods *at some certain point* in the program.
> What JEP 165 is proposing can only statically configure JIT behaviors for
> HotSpot. The same approach doesn't seem to cover what J9 used to support.
>
> Could you please share more background on the discussions that led to the
> decision?
>
> Thanks,
> Kris
>
> On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks <stuart.ma...@oracle.com>
> wrote:
>
>> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
>>
>> :-)
>>
>>
>> On 9/7/16 2:44 PM, Remi Forax wrote:
>>
>>> Yes, i like this patch :)
>>>
>>> Aleksey, It's worst than what you think because for a lot of people
>>> Compiler == java compiler and not JIT compiler so they try to compile a
>>> .java file with the method compileClasses(String).
>>>
>>> I'm glad this class will disappear soon.
>>>
>>> Rémi
>>>
>>> - Mail original -
>>>
>>>> De: "Aleksey Shipilev" <aship...@redhat.com>
>>>> À: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev" <
>>>> core-libs-dev@openjdk.java.net>
>>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
>>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
>>>>
>>>
>>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>>>>
>>>>> Please review this small patch to deprecate java.lang.Compiler for
>>>>> removal.
>>>>>
>>>>
>>>> Yes, +1.
>>>> This class is very confusing to have these days.
>>>>
>>>> -Aleksey
>>>>
>>>
>
>

Re: RFR(s): 4285505: deprecate java.lang.Compiler

[Krystal Mok]

Hi Stuart,

I see that on the JBS page, your most recent comment says it's been decided
that for JDK9 it's okay to deprecate and forRemoval=true, while also
mentioning the uses of this class in IBM's implementation.

Does that mean IBM has agreed on the deprecation of this class? I thought
J9 had features that allowed Java applications to do fine-grained control
over the JIT compiler at runtime, e.g. force compilation of specified
methods *at some certain point* in the program.
What JEP 165 is proposing can only statically configure JIT behaviors for
HotSpot. The same approach doesn't seem to cover what J9 used to support.

Could you please share more background on the discussions that led to the
decision?

Thanks,
Kris

On Wed, Sep 7, 2016 at 2:50 PM, Stuart Marks 
wrote:

> Tomorrow's headline: Oracle Proposes To Remove Java JIT Compiler
>
> :-)
>
>
> On 9/7/16 2:44 PM, Remi Forax wrote:
>
>> Yes, i like this patch :)
>>
>> Aleksey, It's worst than what you think because for a lot of people
>> Compiler == java compiler and not JIT compiler so they try to compile a
>> .java file with the method compileClasses(String).
>>
>> I'm glad this class will disappear soon.
>>
>> Rémi
>>
>> - Mail original -
>>
>>> De: "Aleksey Shipilev" 
>>> À: "Stuart Marks" , "core-libs-dev" <
>>> core-libs-dev@openjdk.java.net>
>>> Envoyé: Mercredi 7 Septembre 2016 23:34:02
>>> Objet: Re: RFR(s): 4285505: deprecate java.lang.Compiler
>>>
>>
>> On 09/07/2016 11:52 PM, Stuart Marks wrote:
>>>
 Please review this small patch to deprecate java.lang.Compiler for
 removal.

>>>
>>> Yes, +1.
>>> This class is very confusing to have these days.
>>>
>>> -Aleksey
>>>
>>

Re: A bit of sugar for j.u.c.locks with try-with-resources?

[Krystal Mok]

Hi David,

Thanks for the link! I'd reckon it's been brought up before, but I guess I
didn't use the right keywords to get a good search. That's good enough
history for me. It explains every issue I've thought about.

The new Java 9 TWR syntax is still fairly limited, in that it still doesn't
support the try (locker(lock)) { ... } usage. The new TWR syntax was just
extended to allow effectively final variables in the TWR header...

Best regards,
Kris

On Sat, Sep 3, 2016 at 12:17 AM, David Holmes <david.hol...@oracle.com>
wrote:

> Hi Kris,
>
> On 3/09/2016 12:41 PM, Krystal Mok wrote:
>
>> Hi core-libs developers,
>>
>> I mostly live down in the VM world, but recently I've been playing with
>> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API
>> with the try-with-resources syntax. I wonder if anybody has brought this
>> topic up before; apologies if there had been.
>>
>
> Yes brought up a few times. :)
>
> https://dzone.com/articles/project-coin-try-resources
>
> If the syntax is more permissive now then it might be more feasible.
>
> Cheers,
> David
>
>
> From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical
>> usage:
>>
>>  class X {
>>private final ReentrantLock lock = new ReentrantLock();
>>// ...
>>
>>public void m() {
>>  lock.lock();  // block until condition holds
>>  try {
>>// ... method body
>>  } finally {
>>lock.unlock()
>>  }
>>}
>>  }
>>
>> The try...finally construction really pops out as a try-with-resources
>> candidate.
>>
>> So what if we retrofit that with something like:
>>
>>  class X {
>>private final ReentrantLock lock = new ReentrantLock();
>>// ...
>>
>>public void m() {
>>  try (lock.lock()) { // block until condition holds
>>// ... method body
>>  }   // automatic unlock at the end
>>}
>>  }
>>
>> Assuming lock.lock() returns a temporary wrapper object (let's call it a
>> "Locker" for this discussion), where Locker implements AutoCloseable, and
>> its close() method calls lock.unlock().
>> That'll make the API look and feel quite similar to the built-in
>> "synchronized () { ... }" syntax. With escape analysis and scalar
>> replacement implemented correctly in the VM, this temporary Locker object
>> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it
>> feels like a pure win to me.
>>
>> What do you think?
>>
>> Best regards,
>> Kris (OpenJDK username: kmo)
>>
>>

Re: A bit of sugar for j.u.c.locks with try-with-resources?

[Krystal Mok]

Hi Vitaly,

Thanks for your comments!

On Fri, Sep 2, 2016 at 7:55 PM, Vitaly Davidovich <vita...@gmail.com> wrote:

> Hi Kris,
>
>
> On Friday, September 2, 2016, Krystal Mok <rednaxel...@gmail.com> wrote:
>
>> Hi core-libs developers,
>>
>> I mostly live down in the VM world, but recently I've been playing with
>> j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API
>> with the try-with-resources syntax. I wonder if anybody has brought this
>> topic up before; apologies if there had been.
>>
>> From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical
>> usage:
>>
>>  class X {
>>private final ReentrantLock lock = new ReentrantLock();
>>// ...
>>
>>public void m() {
>>  lock.lock();  // block until condition holds
>>  try {
>>// ... method body
>>  } finally {
>>lock.unlock()
>>  }
>>}
>>  }
>>
>> The try...finally construction really pops out as a try-with-resources
>> candidate.
>>
>> So what if we retrofit that with something like:
>>
>>  class X {
>>private final ReentrantLock lock = new ReentrantLock();
>>// ...
>>
>>public void m() {
>>  try (lock.lock()) { // block until condition holds
>>// ... method body
>>  }   // automatic unlock at the end
>>}
>>  }
>
> This is Java 9 syntax right? Java 7-8 require an assignment to a local in
> the TWR block.
>

Yes, this is Java 9 syntax, although I was actually intending to use the
old Java 7/8 syntax as the example...got too used to the new goodies.


>
>> Assuming lock.lock() returns a temporary wrapper object (let's call it a
>> "Locker" for this discussion), where Locker implements AutoCloseable, and
>> its close() method calls lock.unlock().
>> That'll make the API look and feel quite similar to the built-in
>> "synchronized () { ... }" syntax. With escape analysis and scalar
>> replacement implemented correctly in the VM, this temporary Locker object
>> wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it
>> feels like a pure win to me.
>>
>> What do you think?
>
> So using TWR with scoped objects, such as this, is used quite a bit; I've
> seen this idiom many times, and have used it myself.
>
> Now, what's the value add to have this in the JDK? One can write such a
> Locker themselves quite easily.
>
> Having the Locker integrated into the API makes the experience smoother.
If we write our own wrapper, it might look like:

try (locker = new Locker(lock)) {
  // ... method body
}

Which is okay-ish. Or maybe with the help of some statically imported
helper method and the Java 9 syntax:

try (locker(lock)) {
  // ...
}

Hmm...I can live with that.

I also don't hold as much confidence in EA as you, apparently - it's too
> brittle and unpredictable in its current form, IMHO.  Of course when the
> allocation doesn't matter, that part isn't a big deal.
>
> Haha, I know how C2's EA isn't giving everybody the kind of confidence
they want. But for simple cases like this it should work nicely (and if
not, let's fix it :-)

And let's say when HotSpot gets a new JIT compiler, it'll have a more
effective EA. All the better.

Thanks,
Kris


> My $.02.
>
>>
>> Best regards,
>> Kris (OpenJDK username: kmo)
>>
>
>
> --
> Sent from my phone
>

A bit of sugar for j.u.c.locks with try-with-resources?

[Krystal Mok]

Hi core-libs developers,

I mostly live down in the VM world, but recently I've been playing with
j.u.c.locks a bit, and saw that there's an opportunity to retrofit the API
with the try-with-resources syntax. I wonder if anybody has brought this
topic up before; apologies if there had been.

>From the JavaDoc of j.u.c.l.ReentrantLock, the following is a typical usage:

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
 lock.lock();  // block until condition holds
 try {
   // ... method body
 } finally {
   lock.unlock()
 }
   }
 }

The try...finally construction really pops out as a try-with-resources
candidate.

So what if we retrofit that with something like:

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
 try (lock.lock()) { // block until condition holds
   // ... method body
 }   // automatic unlock at the end
   }
 }

Assuming lock.lock() returns a temporary wrapper object (let's call it a
"Locker" for this discussion), where Locker implements AutoCloseable, and
its close() method calls lock.unlock().
That'll make the API look and feel quite similar to the built-in
"synchronized () { ... }" syntax. With escape analysis and scalar
replacement implemented correctly in the VM, this temporary Locker object
wouldn't incur much (or any) runtime cost after optimized JIT'ing, so it
feels like a pure win to me.

What do you think?

Best regards,
Kris (OpenJDK username: kmo)

Re: How to change locale in a Windows terminal?

[Krystal Mok]

Hi Max,

Does setting -Duser.country=CN work for you? (I don't remember what the
correct name for China should be, but setting that to US forces java to
print the help message in English)

- Kris

On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang  wrote:

> My Windows 10 is English, but I want the java command to show Chinese help
> screen temporarily.
>
> I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works.
>
> Thanks
> Max
>
>

StackOverflowError on HashMap.hashCode() due to self reference

[Krystal Mok]

Hi Vitaly,

I can buy that argument. It wasn't hard for me to recognize it when I saw
it in real world.

But apparently whoever asked me about it couldn't wrap his head around it
to understand why...

Maybe it's a case for a Pitfalls book instead of for JavaDocs.

Thanks,
Kris

On Friday, July 17, 2015, Vitaly Davidovich vita...@gmail.com
javascript:_e(%7B%7D,'cvml','vita...@gmail.com'); wrote:

 IMHO, this doesn't warrant any special wording -- if someone hits this, I
 think it's fairly evident what the issue is.  You can get the same problem
 with adding an ArrayList to itself and calling hashCode().

 On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok rednaxel...@gmail.com
 wrote:

 Hi everyone,

 I'm sure somebody has seen this stack overflow before. My question is: is
 it expected (which should be documented to warn people not to do this), or
 is it considered a bug (which should be fixed)?

 Example:
 https://gist.github.com/rednaxelafx/930f8979473185cfc0a0

 import java.util.*;

 public class HashMapStackOverflow {
   public static void main(String[] args) throws Exception {
 HashMapString, Object map = new HashMap();
 map.put(self, map);
 System.out.println(map.hashCode());
   }
 }

 $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
 Exception in thread main java.lang.StackOverflowError
 at java.util.AbstractMap.hashCode(AbstractMap.java:505)
 at java.util.Objects.hashCode(Objects.java:98)
 at java.util.HashMap$Node.hashCode(HashMap.java:296)
 at java.util.AbstractMap.hashCode(AbstractMap.java:507)
 at java.util.Objects.hashCode(Objects.java:98)
 at java.util.HashMap$Node.hashCode(HashMap.java:296)
 at java.util.AbstractMap.hashCode(AbstractMap.java:507)
 at java.util.Objects.hashCode(Objects.java:98)
 at java.util.HashMap$Node.hashCode(HashMap.java:296)
 at java.util.AbstractMap.hashCode(AbstractMap.java:507)
 ...

 This will cause a stack overflow because HashMap.hashCode() is inherited
 from AbstractMap, which sums the hash code of each entry, while one of the
 entries is itself so it goes recursive.

 Thanks,
 Kris

StackOverflowError on HashMap.hashCode() due to self reference

[Krystal Mok]

Hi everyone,

I'm sure somebody has seen this stack overflow before. My question is: is
it expected (which should be documented to warn people not to do this), or
is it considered a bug (which should be fixed)?

Example:
https://gist.github.com/rednaxelafx/930f8979473185cfc0a0

import java.util.*;

public class HashMapStackOverflow {
  public static void main(String[] args) throws Exception {
HashMapString, Object map = new HashMap();
map.put(self, map);
System.out.println(map.hashCode());
  }
}

$ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
Exception in thread main java.lang.StackOverflowError
at java.util.AbstractMap.hashCode(AbstractMap.java:505)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
at java.util.Objects.hashCode(Objects.java:98)
at java.util.HashMap$Node.hashCode(HashMap.java:296)
at java.util.AbstractMap.hashCode(AbstractMap.java:507)
...

This will cause a stack overflow because HashMap.hashCode() is inherited
from AbstractMap, which sums the hash code of each entry, while one of the
entries is itself so it goes recursive.

Thanks,
Kris

Re: StackOverflowError on HashMap.hashCode() due to self reference

[Krystal Mok]

Hi Louis,

hanks! I thought I had seen it somewhere but I couldn't recall where.
That's exactly what I need to answer the guys who asked me for a doc
reference.

Thanks,
Kris

On Friday, July 17, 2015, Louis Wasserman lowas...@google.com wrote:

 The Javadoc of Map already specifies:

  Note: great care must be exercised if mutable objects are used as map
 keys. The behavior of a map is not specified if the value of an object is
 changed in a manner that affects equals comparisons while the object is a
 key in the map. *A special case of this prohibition is that it is not
 permissible for a map to contain itself as a key. While it is permissible
 for a map to contain itself as a value, extreme caution is advised: the 
 **equals and hashCode methods
 are no longer well defined on such a map.*

 (emphasis added)

 On Fri, Jul 17, 2015 at 12:11 PM Krystal Mok rednaxel...@gmail.com
 javascript:_e(%7B%7D,'cvml','rednaxel...@gmail.com'); wrote:

 Hi Vitaly,

 I can buy that argument. It wasn't hard for me to recognize it when I saw
 it in real world.

 But apparently whoever asked me about it couldn't wrap his head around it
 to understand why...

 Maybe it's a case for a Pitfalls book instead of for JavaDocs.

 Thanks,
 Kris

 On Friday, July 17, 2015, Vitaly Davidovich vita...@gmail.com
 javascript:_e(%7B%7D,'cvml','vita...@gmail.com');
 javascript:_e(%7B%7D,'cvml','vita...@gmail.com
 javascript:_e(%7B%7D,'cvml','vita...@gmail.com');'); wrote:

  IMHO, this doesn't warrant any special wording -- if someone hits this,
 I
  think it's fairly evident what the issue is.  You can get the same
 problem
  with adding an ArrayList to itself and calling hashCode().
 
  On Fri, Jul 17, 2015 at 2:45 PM, Krystal Mok rednaxel...@gmail.com
 javascript:_e(%7B%7D,'cvml','rednaxel...@gmail.com');
  wrote:
 
  Hi everyone,
 
  I'm sure somebody has seen this stack overflow before. My question is:
 is
  it expected (which should be documented to warn people not to do
 this), or
  is it considered a bug (which should be fixed)?
 
  Example:
  https://gist.github.com/rednaxelafx/930f8979473185cfc0a0
 
  import java.util.*;
 
  public class HashMapStackOverflow {
public static void main(String[] args) throws Exception {
  HashMapString, Object map = new HashMap();
  map.put(self, map);
  System.out.println(map.hashCode());
}
  }
 
  $ ~/sdk/jdk1.8.0/Contents/Home/bin/java HashMapStackOverflow
  Exception in thread main java.lang.StackOverflowError
  at java.util.AbstractMap.hashCode(AbstractMap.java:505)
  at java.util.Objects.hashCode(Objects.java:98)
  at java.util.HashMap$Node.hashCode(HashMap.java:296)
  at java.util.AbstractMap.hashCode(AbstractMap.java:507)
  at java.util.Objects.hashCode(Objects.java:98)
  at java.util.HashMap$Node.hashCode(HashMap.java:296)
  at java.util.AbstractMap.hashCode(AbstractMap.java:507)
  at java.util.Objects.hashCode(Objects.java:98)
  at java.util.HashMap$Node.hashCode(HashMap.java:296)
  at java.util.AbstractMap.hashCode(AbstractMap.java:507)
  ...
 
  This will cause a stack overflow because HashMap.hashCode() is
 inherited
  from AbstractMap, which sums the hash code of each entry, while one of
 the
  entries is itself so it goes recursive.
 
  Thanks,
  Kris
 
 
 

Re: AbstractStringBuilder::append less inlined?

[Krystal Mok]

Hi Bernd,

I agree with Vitaly. Tiered compilation may well be the reason you're
seeing different logging -- in other words, your test is probably too short
so that when tiered compilation is turned on, you're only seeing C1's
compilation logs, and C2 compilation hasn't happened yet.

Try turning on -XX:+TieredCompilation on JDK7u and turning it off on JDK8
for comparison :-)

- Kris


On Thu, Jul 3, 2014 at 5:09 PM, Vitaly Davidovich vita...@gmail.com wrote:

 Hi Bernd,

 Are you testing with tiered compilation on java 8? If so, what happens if
 you turn it off?

 Thanks

 Sent from my phone
 On Jul 3, 2014 8:01 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:

  Hello,
 
  in Java7 (U51 in this case) I do some testing with print inlining,
  and I noticed that all possible executions of
  AbstractStringBuilder::append had been inlined (hot) in thise tests.
  Opposed to that I see a lot of too big messages for Java 8. I wonder if
  this is known/intentional?
 
  (The tests do run faster on 8, so its not a real problem).
 
  Java7
 
  xxx java.lang.AbstractStringBuilder::append (48 bytes)   inline (hot)
 
  and for Java8 (U5, 64bit Windows)
 
  java.lang.AbstractStringBuilder::append (50 bytes)   callee is too large
 
  Greetings
  Bernd
 

Re: How to close a Process and having shutdown hooks called ?

[Krystal Mok]

Hi Nicolas,

Looks like a well discussed question. On Posix systems, SIGTERM should work
for you. That's the default signal sent by the 'kill' command on Linux.
e.g. please take a look here:
http://stackoverflow.com/questions/2541597/how-to-gracefully-handle-the-sigkill-signal-in-java

- Kris


On Tue, Mar 4, 2014 at 2:45 AM, LE PICARD NICOLAS
n.lepic...@chu-tours.frwrote:

 Hello everyone !

 I looked for the answer in this list and did not find anything relevant.

 I don't know it it's possible to close a Process et call shutdown hooks
 automatically. I looked into the code and found it was not possible (in
 jdk7).
 When we call destroy() on a Process, it will call terminateProcess of
 ProcessImpl class.
 This link shows that a TerminateProcess  kills  the process and WH_CBT
 hooks are NOT called.

 http://msdn.microsoft.com/en-us/library/windows/desktop/ms686722(v=vs.85).aspx
 Calling exitProcess (instead of TeminateProcess) seems to be dangerous ...
 but I don't understand why (ok, dlls could be locked, but when you do a
 CTRL +C it calls an exitProcess... so what's the problem ???)

 So I ask  how can we close a process, with the hooks called ? . My
 knowledge is way smaller than people on openjdk... so I hope someone has an
 answer or a workaround.

 Byte the way, I looked for sending signals (SIGINT for Windows, SIGKILL
 for linux etc) to close a process.
 Maybe I'm wrong, but a solution could be to add to ProcessImpl_md.c :

 #include signal.h



 JNIEXPORT jboolean JNICALL

 Java_java_lang_ProcessImpl_CloseHandleWithHooks(JNIEnv *env, jclass
 ignored, jlong handle)

 {

 raise(SIGINT) ;

 }

 I think,it will call an ExitProcess so ... dangerous or not ?
 Of course, we have to add also a function in ProcessImpl and make call
 available from Process through an abstract function like  close() 


 Any clever thoughts on this subject (I'm sure it is a common problem...) ?
 Thanks :)


 Regards.

 Nicolas Le Picard

Re: Getting ciObject from oop/jobject

[Krystal Mok]

Hi Nick,

This topic is related to HotSpot Server Compiler instead of the Java core
library, so I'm cc'ing this email to hotspot-compiler-dev and dropping
core-libs-dev.

As you already know, HotSpot compilers are shielded from VM runtime
implementation details via the Compiler Interface (CI). That's why you
shouldn't be getting raw oops in C2 code.

Where are you getting the oopInstance from? If it can be found from some
known roots, e.g. well-known classes, fields of well-known classes,
or the holder class of the method to be compiled, etc., then it's already
available through CI.

- Kris


On Thu, Aug 1, 2013 at 3:17 AM, Nick Williams 
nicholas+open...@nicholaswilliams.net wrote:

 In native code (library_call.cpp), if I have an oop (which I can convert
 to a jobject if need be), how do I get a ciObject? I see that ciEnv has a
 ciObject* get_object(oop) method, but it's private. And ciObjectFactory has
 a ciObject* get(oop) method, but I can't figure out how to get the
 ciObjectFactory instance.

 I know that ciObject keeps a jobject internally, and I know that ciObject
 has a ciObject(oop) constructor, but it's protected (for good reason).

 If it helps, I'm trying to inline a method and need to
 set_result(makecon(TypeInstPtr::make(oopInstance))). I may be going down
 the wrong path.

 Thanks in advance for any help,

 Nick

Re: Request for Review : CR#6924259: Remove String.count/String.offset

[Krystal Mok]

Hi Nazario,

That's a typical substring leak case. Matcher.group(n) eventually calls
String.substring() to return the result. Before removing the count and
offset fields in String, that'll return a String sharing the value char
array, which may cause memory leaks if you hold on to a small substring of
a large string.

It's not your HashSet leaking memory, just the substring.

- Kris


On Fri, Apr 12, 2013 at 9:50 PM, wangsheng.0376 wangsheng.0...@163.comwrote:

 hi, all,

 I agree with you to remove offset, today when I run following code in
 jdk7(sorry I forget the detail version), my code is like this:




 Pattern pattern = Pattern.compile(regex);

 Matcher matcher = pattern.match(content);

 while (matcher.find()) {

  String link = matcher.group(1);

  set.add(link);// set is a HashSet type

 }




 after I running for some time, I found that the 'set' object has memory
 leak, I found though 'link' is a part of 'content', but the value field in
 link variable is same as 'content' value field, difference is that the link
 offset field is not zero.

 So that mean the set(HashSet) is not store the 'link', it store the
 'content' value field, it will cause the memory leak problem, So I am very
 happy to reomve the offset field.




 Best Regards

 =nazario.wang=

Re: about SuppressWarnings

[Krystal Mok]

Hi,

If you're using javac to compile your Java source code, than you can try
running
javac -X
to see the list of -Xlint options. That'll give you a hint of what warnings
can be suppressed.

As from the JavaDoc [1], the warning names are vendor specific. So if
you're not using javac then youll need to find out what warnings your
compiler supports.

- Kris

[1]:
http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html

On Sun, Nov 4, 2012 at 9:19 PM, fuyou fuyou...@gmail.com wrote:

 hi
   all
When I use @SuppressWarnings in program.
   I only know some  ,ex
  @SuppressWarnings(unchecked),@SuppressWarnings(unused).
   what others?

 --
=

   fuyou001
 Best Regards

Re: StackTraceElement question

[Krystal Mok]

On Mon, Oct 8, 2012 at 7:27 AM, David Holmes david.hol...@oracle.comwrote:

 On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulaschris...@zoulas.com
  wrote:

  Hi,

 I don't know if this belongs to this list, but if it does not,
 please point me to where it does. I think that it would be nice if
 StackTraceElement which currently contains:

  boolean equals(Object obj)
  String  getClassName()
  String  getFileName()
  int getLineNumber()
  String  getMethodName()
  int hashCode()
  boolean isNativeMethod()
  String  toString()

 It would be more useful for it to also contain:

  Class? getClass()

 The reason I am asking, is because I have an application where I
 would like to find the enclosing class from where the exception is
 thrown not the superclass, but I cannot deduce that from the class
 name. If STE contained the above method, I could do:

  Class?  c = ste.getClass();
  while (c.getEnclosingClass() != null) {
   c = c.getEnclosingClass();
  }
  return c.getName();


 Can't you just do Class.forName(getClassName()) and then find the
 enclosing class?

 There could be potential class loader issues to
use Class.forName(getClassName()) in this case (most probably caused by
reflective calls).
But then again, giving the user a reference to instead of the name of a
class really gives the user more information then what's been given now
(e.g. class loader info). Which is not necessarily a good thing. I'd second
Alan on having to do more analysis.

- Kris


 David
 -


  to find the class I want, and getClassName() could be just a wrapper:

  String getClassName() {
  return getClass().getName();
  }

 Is there any reason to store the name instead of the Class?? Is it
 possible to fix this in a future version of the jdk?

 thanks

 christos

Re: StackTraceElement question

[Krystal Mok]

On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas chris...@zoulas.comwrote:

 On Oct 8, 11:07pm, david.hol...@oracle.com (David Holmes) wrote:
 -- Subject: Re: StackTraceElement question

 |  There is also the problem of having a class hierarchy like:
 | 
 |  class A extends class I
 |  class B extends class I
 | 
 |  and then trying to figure out if it is A or B when you just have I from
 |  that StackTraceElement.
 |
 | Can't say I have ever studied stacktraces in depth but I would expect to
 | see A or B not I as the name.

 I was expecting the same, but this is not the case:

 $ cat StackTrace.java
 class I {
 public void run()
 throws Exception
 {
 throw new Exception();
 }
 }

 class A
extends I
 {
 }

 public class StackTrace {
 public static void main(String[] args) {
 try {
 A a = new A();
 a.run();
 } catch (Exception e) {
 StackTraceElement[] ste = e.getStackTrace();
 for (int i = 0; i  ste.length; i++)
 System.out.println(ste[i].getClassName());
 }
 }
 }
 $ javac Stacktrace.java
 $ java -cp . StackTrace
 I
 StackTrace

 Printing I here is expected. After all, that's the class where you're
getting run()'s implementation from.
It's not designed to tell people the actual type of the receiver of a
certain method invocation. And that's what you're really after, right?

- Kris



 | The loader issue is real, you'd have to know where to locate the class.
 | But another reason to not store the Class reference is that it may
 | prevent the class from being unloaded. For every use-case there's a
 | counter-use-case.

 Yes, the class loader issue is real. I am not sure about the Class
 reference preventing the class to be unloaded; after all, the
 StackTraceElements are typically transient (when the exception goes
 out of context, they can be GC'ed); if not, then the reference can
 be held until the StackTraceElement is not reachable. I don't think
 that keeping the reference is such a big issue to even consider
 making this Weak. I am really worried about the security implications.
 As far as serialization goes, it could be made transient for
 compatibility.  Anyway, I would be more than happy the StackTraceElement
 contained the outermost enclosing class instead of the immediately
 enclosing one.  Returning the Class? instance is still the most
 versatile, but the one that needs most consideration because of its
 implications.

 christos

 christos

Re: StackTraceElement question

[Krystal Mok]

Hi,

I believe this discussion belongs to core-libs-dev list better. cc'd.

- Kris

On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas chris...@zoulas.com wrote:

 Hi,

 I don't know if this belongs to this list, but if it does not,
 please point me to where it does. I think that it would be nice if
 StackTraceElement which currently contains:

 boolean equals(Object obj)
 String  getClassName()
 String  getFileName()
 int getLineNumber()
 String  getMethodName()
 int hashCode()
 boolean isNativeMethod()
 String  toString()

 It would be more useful for it to also contain:

 Class?getClass()

 The reason I am asking, is because I have an application where I
 would like to find the enclosing class from where the exception is
 thrown not the superclass, but I cannot deduce that from the class
 name. If STE contained the above method, I could do:

 Class? c = ste.getClass();
 while (c.getEnclosingClass() != null) {
  c = c.getEnclosingClass();
 }
 return c.getName();

 to find the class I want, and getClassName() could be just a wrapper:

 String getClassName() {
 return getClass().getName();
 }

 Is there any reason to store the name instead of the Class?? Is it
 possible to fix this in a future version of the jdk?

 thanks

 christos

Re: typo in comments of JVM_SupportsCX8 in jvm.h

[Krystal Mok]

On Fri, Jun 8, 2012 at 4:39 AM, chris hegarty chris.hega...@oracle.comwrote:

 Looks fine Kris (given the same change is being made to
 hotspot/src/share/vm/prims/**jvm.h)

 Yes. jvm.h in both the hotspot and jdk workspaces had incorrect comments
on JVM_SupportsCX8 before this change, but they were different because they
were out of sync.


 I can sponsor this for you. We can use the same bug number seeing as these
 are two separate repositories.

 Great. Thank you, Chris!

- Kris


 -Chris.

Re: Review Request CR#7118743 : Alternative Hashing for String with Hash-based Maps

[Krystal Mok]

Hi Mike,

On Fri, May 25, 2012 at 10:12 AM, Mike Duigou mike.dui...@oracle.comwrote:


 On May 24 2012, at 16:32 , Vitaly Davidovich wrote:

  That's a bit odd as I thought the Klass object in the VM stored
 something like 7 supers, which includes interfaces (if I'm not mistaken).
  I know that instanceof checks against final classes are optimized into a
 simple cmp against an address, but I'm surprised that a check against an
 interface for classes in a very shallow type hierarchy is up to x25 slower.
  Do you know why that is Mike? Did you ask the compiler guys by chance?
 
 I didn't actually look much further into it other than to write a small
 microbenchmark to make sure it was the instanceof check. I tested a couple
 of different configs of classes and interfaces and supers. I was able to
 validate that 'x instanceof String'  was as fast as 'x.getClass() ==
 String.class' and that other cases were slower. Inheritance checks seemed
 faster than checks on interfaces. That was enough to tell me that I was on
 the wrong track with 'x instanceof Hashable' as a way to determine which
 hash algorithm to use. At least for C2 server compiler.

 FYI, x.getClass() == String.class will be just as fast when 7170463 [1]
is in.

@Vitaly

The fast subtype checking algorithm in HotSpot treats interfaces as
secondary supers, which goes through a slow path. The super type display
in instanceKlass is only for primary supers, which does not include
interfaces for instance classes. You may want to check out the details in
this paper [2].

 Definition 5:  A class T is a secondary type iff T is an interface or
 an array of a secondary type. Every type is either a primary
 type or a secondary type but not both.

Regards,
Kris

[1]:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007730.html
[2]: http://dl.acm.org/citation.cfm?id=583821


 If there is a thorough exploration or explanation of which dispatching
 techniques have good performance and an explanation of which idioms will
 never be fast I'd be interested to read it.

 Mike
  Thanks
 
  Sent from my phone
 
  On May 24, 2012 5:26 PM, Mike Duigou mike.dui...@oracle.com wrote:
 
  On May 23 2012, at 16:31 , David Holmes wrote:
 
   On 24/05/2012 2:24 AM, Mike Duigou wrote:
   Hi Mike;
  
   The problem with using instanceof Hashable32 is that is much slower
 (often more than 25X) than instanceof String. It's slow enough that we
 won't reasonably consider using instanceof Hashable32 in JDK 8. We have
 considered making Object implement Hashable32 and add a virtual extension
 method to Object for hash32(). The extension method would just call
 hashCode(). A compiler that supports extension methods is not yet part of
 the JDK mainline repo yet (It is still in the Lambda repo). This approach
 would mean that we can avoid an instanceof check but there is a *lot* of
 entirely reasonable reservations about having Object implement an interface
 and gain a new method.
  
   Is it worth using:
  
(k instanceof String || k instanceof Hash32)
  
   to deal with that. What would be the penalty on non-String Hash32's?
 
  The problem in this case would be the k instances that are neither
 String nor Hash32. They would be severely impacted. Using Doug Lea's
 loops Map microbenchmark, k instanceof Hash32 was up to 25 times more
 expensive than calling k instanceof String. I suspect that it could be
 even higher with classes that have deep inheritance hierarchies. My
 non-Hash32 keys were all instances of Number (Float, Double, Integer and
 Long) so each had a single interface.
 
  Mike
 
   David
  
   Opinions and insights welcome,
  
   Mike
  
   On May 23 2012, at 00:38 , Mike Skells wrote:
  
   Hi Mike,
  
   I have a query, why is this implementation limitted to String?
   Is this by intent?
  
   in HashMap the patch for hash calculation is
290 final int hash(Object k) {
291 int h = hashMask;
292 if ((0 != h)  (k instanceof String)) {
293 return h ^ ((String)k).hash32();
   
   whereas I would have thought that it should be
290 final int hash(Object k) {
291 int h = hashMask;
292 if ((0 != h)  (k instanceof Hash32)) {
293 return h ^ ((Hash32)k).hash32();
   
  
   As a more flexible improvement could you supply a HashCode and
 Equals delegate, and then the user can supply either a custom delegate,
 suitable for that application (e.g.one that iterates through array content,
 or any other application data structure that needs to be handled
 differently like c# uses
 http://msdn.microsoft.com/en-us/library/system.collections.iequalitycomparer)
  
   Regards
  
   Mike
  
 

Re: Need reviewer: JDK 8 CR for Support Integer overflow

[Krystal Mok]

Hi Florian,

On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer fwei...@bfk.de wrote:

 Will Hotspot be able to optimize away the string construction on the
 exception path in multiplyExact() if the exception is caught locally?

 At least -XX:+OptimizeStringConcat should remove the need to construct a
StringBuilder instance, in multiplyExact()'s case.

Cc'ing hotspot-compiler-dev for confirmation.

- Kris

Re: Need reviewer: JDK 8 CR for Support Integer overflow

[Krystal Mok]

Hi Tom,

Yes, I'm sorry for not including enough context when cc'ing.

The original discussion thread starts from [1]. The webrev is at [2].

For the string concats in multiplyExact():
* the StringBuilder doesn't escape
* it's only concatenating Strings and ints

which should meet the requirements for OptimizeStringConcat to work,

Regards,
Kris Mok

[1]:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-February/009128.html

[2]:  http://cr.openjdk.java.net/~rriggs/CR6708398/webrev/

On Sat, Feb 4, 2012 at 1:47 AM, Tom Rodriguez tom.rodrig...@oracle.comwrote:


 On Feb 3, 2012, at 12:38 AM, Krystal Mok wrote:

  Hi Florian,
 
  On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer fwei...@bfk.de wrote:
  Will Hotspot be able to optimize away the string construction on the
  exception path in multiplyExact() if the exception is caught locally?
 
  At least -XX:+OptimizeStringConcat should remove the need to construct a
 StringBuilder instance, in multiplyExact()'s case.
 
  Cc'ing hotspot-compiler-dev for confirmation.

 Could we have some context?

 tom

 
  - Kris
 
 

Re: typo in sun.misc.VM's comment

[Krystal Mok]

Hi Chris and Remi,

Thank you very much :-)

Regards,
Kris Mok

On Tue, Jan 10, 2012 at 6:58 PM, Rémi Forax fo...@univ-mlv.fr wrote:

 On 01/10/2012 11:43 AM, Chris Hegarty wrote:

 I created CR 7128584: Typo in sun.misc.VM's private directMemory field
 comment, for this issue, and will push Kris' change with Remi and myself
 as reviewer and listing Kris as the contributor.

 Thanks,
 -Chris.


 Thanks,
 Rémi



 On 01/10/12 08:22 AM, Rémi Forax wrote:

 I think it's better if it has it's own bug id and changeset.
 I'm sure Joe can create a bug id for it.

 Rémi

 On 01/10/2012 06:51 AM, Krystal Mok wrote:

 Hi all,

 Just found a little typo in sun.misc.VM:

 diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.**java
 --- a/src/share/classes/sun/misc/**VM.java Thu Nov 17 10:46:02 2011
 -0800
 +++ b/src/share/classes/sun/misc/**VM.java Tue Jan 10 13:42:52 2012
 +0800
 @@ -167,7 +167,7 @@
 //
 // The initial value of this field is arbitrary; during JRE
 initialization
 // it will be reset to the value specified on the command line, if any,
 - // otherwise to Runtime.getRuntime.**maxDirectMemory().
 + // otherwise to Runtime.getRuntime().**maxMemory().
 //
 private static long directMemory = 64 * 1024 * 1024;


 I was looking for the default max direct memory size when I found this
 comment. It would have been nice if this typo was fixed in 6977738. [1]
 Could anybody include this fix in some future commits?

 Regards,
 Kris Mok

 [1]: 
 http://hg.openjdk.java.net/**jdk8/jdk8/jdk/rev/b444f86c4abehttp://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe

typo in sun.misc.VM's comment

[Krystal Mok]

Hi all,

Just found a little typo in sun.misc.VM:

diff -r 00e2c88e2234 src/share/classes/sun/misc/VM.java
--- a/src/share/classes/sun/misc/VM.java Thu Nov 17 10:46:02 2011 -0800
+++ b/src/share/classes/sun/misc/VM.java Tue Jan 10 13:42:52 2012 +0800
@@ -167,7 +167,7 @@
 //
 // The initial value of this field is arbitrary; during JRE
initialization
 // it will be reset to the value specified on the command line, if any,
-// otherwise to Runtime.getRuntime.maxDirectMemory().
+// otherwise to Runtime.getRuntime().maxMemory().
 //
 private static long directMemory = 64 * 1024 * 1024;


I was looking for the default max direct memory size when I found this
comment. It would have been nice if this typo was fixed in 6977738. [1]
Could anybody include this fix in some future commits?

Regards,
Kris Mok

[1]: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/b444f86c4abe