spot/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
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
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]
an 26, 2018 at 12:06 AM, Seán Coffey
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,
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 sou
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.
>
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,
navoidably platform-specific. Users of this API
> would be better served by using a platform-specific API. Can't Azul create
> one and migrate to it?
>
> s'marks
>
>
> On 9/13/16 5:09 PM, Krystal Mok wrote:
>
> Hi OpenJDK developers,
>
> Replying on beha
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 example
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 wrote:
> On 07/09/16 23:45, Krystal Mok wrote:
> > I see that on the JBS page, your most recent comment says it&#x
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
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 f
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
wrote:
> Hi Kris,
>
> On 3/09/2016 12:41 PM, Krystal
Hi Vitaly,
Thanks for your comments!
On Fri, Sep 2, 2016 at 7:55 PM, Vitaly Davidovich wrote:
> Hi Kris,
>
>
> On Friday, September 2, 2016, Krystal Mok wrote:
>
>> Hi core-libs developers,
>>
>> I mostly live down in the VM world, but recently I've been
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
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 c
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
Friday, July 17, 2015, Vitaly Davidovich > 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().
>
> O
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.*;
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 o
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
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
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
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
On Mon, Oct 8, 2012 at 10:25 PM, Christos Zoulas wrote:
> 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 clas
On Mon, Oct 8, 2012 at 7:27 AM, David Holmes wrote:
> On Sat, Oct 6, 2012 at 3:04 AM, Christos Zoulas
>> 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 curr
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 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
> StackTraceElem
On Fri, Jun 8, 2012 at 4:39 AM, chris hegarty wrote:
> 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 t
Hi all,
As discussed on hotspot-compiler-dev [1], I came across a typo in the
exported jvm.h in the jdk workspace while working on 7174218.
The fix is simple [2], and sync up with the changes in 7174218:
diff -r 7def50698e78 src/share/javavm/export/jvm.h
--- a/src/share/javavm/export/jvm.h Thu Ma
Hi Mike,
On Fri, May 25, 2012 at 10:12 AM, Mike Duigou wrote:
>
> 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
eet 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 wrote:
>
> On Feb 3, 2012
Hi Florian,
On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer 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
StringBuil
#x27;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
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
34 matches
Mail list logo
