On Thu, Feb 12, 2015 at 1:07 AM, Alan Bateman
wrote:
> On 12/02/2015 02:08, Martin Buchholz wrote:
>
>> Roger et al,
>>
>> Whichever way we go doesn't matter much.
>> But I continue to think that IOE is a better choice than UOE and I have
>> trouble seeing the motivation for the change to use UOE
Hi Claes,
Thanks a lot for the clarification! I'm glad this has been optimized in
JDK9!
Also, your example with "foo" and "" makes sense.
Thanks!
Zoltan
On Wed, Feb 18, 2015 at 4:51 PM, Claes Redestad
wrote:
> Hi Zoltan,
>
> 1. Well, obviously, there's an empty string at the end of all String
I just filed a bug report with Oracle (Review ID: JI-9019070) requesting that
Comparators.NullComparator
implement equals and hashCode in a manner analogous to
Collections.ReverseComparator2. It occurred
to me that my bug report failed to mention the (hopefully obvious) behavior
regarding the nu
On 17/02/15 19:21, Vitaly Davidovich wrote:
> IMO I don't think such barriers should be removed just because EA is able
> to elide the heap allocation.
Why not? Are you assuming that the programmer might be relying on a
memory barrier being implied in interpreted/JITted code by the presence
in the
Hi Zoltan,
1. Well, obviously, there's an empty string at the end of all Strings which
you can index into! ;-)
(I guess it was a coin toss originally. Since it'd be a bit
inconsistent if say "foo".substring(0, 0) returned "" while, say,
"".substring(0, 0) threw a tantrum, I'd like to think the c
Hi,
There are 2 things I do not understand about how substring works, hopefully
someone can shed some light on it.
1. When you call substring and you provide the string's length as
beginIndex, why does it return an empty string instead of throwing an
exception? You are effectively indexing outsid
Thanks Vladimir. I was actually asking about the ByteBuffer elimination
itself; when I tried Andrew's example on 7u60 (i.e. a single method with a
ByteBuffer.wrap(...).getLong(...)), the ByteBuffer allocation was not
removed.
On Wed, Feb 18, 2015 at 3:59 PM, Vladimir Kozlov wrote:
> The code wh
The code which eliminates MemBars for scalarized objects was added in jdk8:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
An other store barrier change was also pushed into jdk8:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6
I don't remember we did anything spec
Hi Joe, core libs developers,
Last night we had a hackathon in Bulgarian Java User Group. Its purpose was
to work on fixing some compiler warnings in OpenJDK. The day before the
meeting we ran the following command:
make clean
JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked,cast,serial,
On 02/18/2015 02:32 PM, David M. Lloyd wrote:
> It's an awful lot of pain to avoid what IMO should be an obvious addition:
>
> (Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,]
> byte[] b, int offs)
>
> This could (it seems to me) be easily intrinsified, is hugely useful
Hi Mark,
Looks fine as is.
The malloc could also be moved inside the if (SetupI18nProps...
but that's a bigger change.
Roger
On 2/18/2015 9:44 AM, Mark Sheppard wrote:
Hi
please oblige and review the small change
http://cr.openjdk.java.net/~msheppar/8055204/webrev/
which addresses the pa
Ok, perhaps I misunderstood then since you mentioned Unsafe.storeFence() in
your earlier post and Vladimir said they were debating whether these fences
should be removed. If you guys were talking only about the final field
fence, then my bad, I don't disagree with removing those if the object
does
On Feb 18, 2015, at 12:47 AM, Alan Bateman wrote:
> On 17/02/2015 21:56, Brian Burkhalter wrote:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
>>
>>
> It's good to see this changed to throw IAE. What about other methods that
> take a key (like get), do they
On 02/18/2015 02:16 PM, Vitaly Davidovich wrote:
> I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
> I don't think compiler can prove that it's safe to do so.
Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be
removed.
We're talking about fences at t
Hi Jason,
On 18/02/15 16:13, Jason Mehrens wrote:
Daniel,
Was it determined if you were going to modify the existing logger.dtd or create
a logger-v2.dtd? If you are going to create a v2 then I think it might make
sense to make dtd log manger property for the XMLFormatter instead of
useIns
Daniel,
Was it determined if you were going to modify the existing logger.dtd or create
a logger-v2.dtd? If you are going to create a v2 then I think it might make
sense to make dtd log manger property for the XMLFormatter instead of
useInstant property. So if you are using v2 then instant i
Hi
please oblige and review the small change
http://cr.openjdk.java.net/~msheppar/8055204/webrev/
which addresses the parfait issue raised in
https://bugs.openjdk.java.net/browse/JDK-8055204
frees previously allocated memory in an error return path.
regards
Mark
It's an awful lot of pain to avoid what IMO should be an obvious addition:
(Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,]
byte[] b, int offs)
This could (it seems to me) be easily intrinsified, is hugely useful
both within and outside of the JDK, and fits perfectly w
Indeed, that's quite nice and not what I saw in java 7 so good to see that
this case is EA'd out. Does anyone know if there was EA work done in java
9 or is this simply inlining policy change that makes EA work (as John
alluded to)?
sent from my phone
On Feb 18, 2015 6:13 AM, "Andrew Haley" wrot
I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
I don't think compiler can prove that it's safe to do so. When value types
come to be and get scalarized, it may be possible to create cheap
synchronization types that are stack allocated yet are used for
synchronization c
Hi Alan,
as I understand it,
it is a case that the switch statement doesn't have an explicit default
case, and as such it is seen that there is the potential
for exc to return garbage as it is a local (stack) variable.
code exc.return is not explicitly initialized in that scenario
I have foll
On 18/02/2015 13:29, Mark Sheppard wrote:
Hi
please review the small change
http://cr.openjdk.java.net/~msheppar/8051990/webrev/
to address the parfait issue in
https://bugs.openjdk.java.net/browse/JDK-8051990
Is this a false positive or is there really something calling
__kernel_standard w
Hi
please review the small change
http://cr.openjdk.java.net/~msheppar/8051990/webrev/
to address the parfait issue in
https://bugs.openjdk.java.net/browse/JDK-8051990
regards
Mark
On 02/18/2015 09:15 AM, Andrew Haley wrote:
> On 18/02/15 09:14, Florian Weimer wrote:
>> Wow, looks nice. What OpenJDK build did you use? I want to see if this
>> happens on x86_64, too.
>
> I'm working on JDK9. You don't have this code yet. I'll do an x86
> build.
0x7f2948acbf8c: mov
In LogRecord, the Javadoc of getInstant():
"Get event time."
could be
"Gets the instant that the event ocurred."
In LogRecord, the Javadoc of setInstant():
"Set event time."
could be
"Sets the instant that the event ocurred."
(matching change to @param)
I'd prefer to see the other methods in the
On 02/18/2015 10:01 AM, Andrew Dinn wrote:
> On 17/02/15 19:21, Vitaly Davidovich wrote:
>> IMO I don't think such barriers should be removed just because EA is able
>> to elide the heap allocation.
>
> Why not? Are you assuming that the programmer might be relying on a
> memory barrier being impl
On 17/02/2015 21:56, Brian Burkhalter wrote:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031502.html
It's good to see this changed to throw IAE. What about other methods
that take a key (like get), do they need their javadoc updated too?
-Alan
27 matches
Mail list logo
