Joe / Andrew / Louis,
Following up on the thread regarding
https://bugs.openjdk.java.net/browse/JDK-8032027.
I revised the algorithm similarly to what Louis suggested for the initial value
of the iteration. I also tightened up the memory usage. The updated version is
here:
http://cr.openjdk.j
Hi,
Please review my doc/spec change (no code) for 8138824.
Bug: https://bugs.openjdk.java.net/browse/JDK-8138824
Webrev: http://cr.openjdk.java.net/~bchristi/8138824/webrev.0/
Specdiff:
http://cr.openjdk.java.net/~bchristi/8138824/specdiff.0/overview-summary.html
This change addresses a long
On 7 October 2015 at 23:24, Roger Riggs wrote:
> Please consider and comment:
>
> T nonNullOf(T obj, T defaultObj);
> T nonNullOf(T, obj, Supplier defaultSupplier);
>
> Details are in the updated webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-object-non-null/
I think I can liv
Hi,
The original intent was to simplify the filling in of default values
(even if null).
I took Remi's point about the canonical coalescing operator not always
returning non-null
but the push seems to be in the direction of making sure the result is
always non-null.
I'd rather add a few very
On Oct 5, 2015, at 2:41 AM, Andrew Haley wrote:
>
> Hi Gil,
>
> On 04/10/15 17:22, Gil Tene wrote:
>
>> Summary
>>
>> Add an API that would allow Java code to hint that a spin loop is
>> being executed.
>
>
> I don't think this will work for ARM, which has a rather different
> spinlock mecha
On 07/10/2015 20:57, Chris Hegarty wrote:
:
I updated Connection with a readFully that has the same
semantics as IOUtils.
http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/
I agree with Roger. Couldn't this be changed to use create an array of
length seqlen and use readNBytes?
-Al
Hi,
Yea, but now we have duplicated code...
Does it ever go away?
Roger
On 10/7/2015 3:57 PM, Chris Hegarty wrote:
On 7 Oct 2015, at 20:15, Chris Hegarty wrote:
On 7 Oct 2015, at 20:04, Alan Bateman wrote:
On 07/10/2015 19:19, Chris Hegarty wrote:
This primary motivation behind this b
Hello,
Actually I am searching through the JBS for low hanging fruits.
Right now i am looking through the openjdk-sources and try to evaluate
if i can make something about JDK-5108778.
Please find my webrevs for the jdk, jaxp, jaxws and corba repos at:
http://cr.openjdk.java.net/~sebastian/51087
On 7 Oct 2015, at 20:15, Chris Hegarty wrote:
> On 7 Oct 2015, at 20:04, Alan Bateman wrote:
>
>> On 07/10/2015 19:19, Chris Hegarty wrote:
>>> This primary motivation behind this bug [1] is the clearing out of
>>> sun.misc, in preparation for JEP 260 [2].
>>>
>>>
>> It would be nice if com/
On 7 Oct 2015, at 20:04, Alan Bateman wrote:
> On 07/10/2015 19:19, Chris Hegarty wrote:
>> This primary motivation behind this bug [1] is the clearing out of
>> sun.misc, in preparation for JEP 260 [2].
>>
>>
> It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use
> sun.sec
On 07/10/2015 19:19, Chris Hegarty wrote:
This primary motivation behind this bug [1] is the clearing out of
sun.misc, in preparation for JEP 260 [2].
It would be nice if com/sun/jndi/ldap/Connection.java didn't have to use
sun.security.util.IOUtils, could that one be fixed? The rest look fi
Hi Chris,
Looks fine.
The change in exception message is more informative than the previous
exception message.
Roger
On 10/7/2015 2:19 PM, Chris Hegarty wrote:
This primary motivation behind this bug [1] is the clearing out of
sun.misc, in preparation for JEP 260 [2].
sun.misc.IOUtils is
This primary motivation behind this bug [1] is the clearing out of
sun.misc, in preparation for JEP 260 [2].
sun.misc.IOUtils is a JDK internal convenience utility class that
provides a single method that offers bulk blocking InputStream read
semantics. In 9, java.io.InputStream has been retrofitt
On 7 Oct 2015, at 16:55, Paul Sandoz wrote:
>
>> On 6 Oct 2015, at 10:58, Chris Hegarty wrote:
It was not immediately obvious to me that the common prefix can be 0.
Should this be called out specifically?
>>>
>>> When reading the documentation of compare or mismatch or both?
>
On 10/07/2015 04:45 PM, Gil Tene wrote:
> For ARM, I expect WFE/SEV to need to evolve as well, and for other
> reasons, even fit use within OSs. The current WFE/SEV scheme is not
> scalable. While it probably works ok for spinning at the kernel
> level on hardware that only has s handful of cores,
> On 6 Oct 2015, at 10:58, Chris Hegarty wrote:
>>> It was not immediately obvious to me that the common prefix can be 0.
>>> Should this be called out specifically?
>>>
>>
>> When reading the documentation of compare or mismatch or both?
>
> mismatch. But maybe this is just me.
>
I could
On 10/07/2015 04:45 PM, Gil Tene wrote:
> In any case, even if it were user-mode-accessible, MWAIT may not appropriate
> for latency-sensitive spinning because it can apparently take 1000s of cycles
> to come out of the C-state modes it goes into.
Oh, yuck. OK, forget it.
Thanks,
Andrew.
Sent from Gil's iPhone
> On Oct 7, 2015, at 1:14 AM, Andrew Haley wrote:
>
>> On 05/10/15 21:43, Gil Tene wrote:
>>
>> I see SpinLoopHint as very separate from things like MONITOR/WAIT
>> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice
>> way until this state changes" inst
Hi,
I have pushed an implementation of the prototype
in the sandbox.
The branch name is JDK-8046565-branch
Instructions for cloning a sandbox branch can be found here:
http://cr.openjdk.java.net/~chegar/docs/sandbox.html
best regards,
-- daniel
On 05/10/15 12:54, Daniel Fuchs wrote:
New JEP
Hi,
please review and sponsor this AIX fix.
in ResolverConfigurationImpl.c, we may crash because strchr() is used
without prototype, which causes the C compiler to default to an int return
type, which means we loose the upper 32bit of the pointer returned by
strchr().
The solution is to include
The current guideline seems to be that new collections introduced after Java 4
should not allow null.
ArrayDeque is an example of such collections.
This proposal introduces new static methods on both interfaces and
implementations.
Interface static methods use new immutable collections, if those
On 7 Oct 2015, at 10:30, Stephen Colebourne wrote:
> On 7 October 2015 at 01:13, Stuart Marks wrote:
>> My question is, is this enough of a problem that we should allow nulls in
>> these collections? I would prefer not to do this, but if there is evidence
>> that this would be a mistake, I'd lik
On 7 October 2015 at 01:13, Stuart Marks wrote:
> My question is, is this enough of a problem that we should allow nulls in
> these collections? I would prefer not to do this, but if there is evidence
> that this would be a mistake, I'd like to hear it.
>
> And if disallowing nulls will cause deve
On 05/10/15 21:43, Gil Tene wrote:
> I see SpinLoopHint as very separate from things like MONITOR/WAIT
> (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice
> way until this state changes" instructions that other architectures
> may have or add.
>
> Mechanisms like MONITOR/WAIT and
> On Oct 6, 2015, at 6:50 PM, Joseph D. Darcy wrote:
>
>
> On 10/6/2015 6:28 PM, Gil Tene wrote:
>>> On Oct 6, 2015, at 1:02 PM, Doug Lea wrote:
>>>
>>> On 10/04/2015 12:22 PM, Gil Tene wrote:
I would like to circulate this draft JEP proposal for initial review and
consensus buildi
25 matches
Mail list logo
