Hi Aleksey,
On 19/08/2016 4:31 PM, Aleksey Shipilev wrote:
On 08/19/2016 08:15 AM, David Holmes wrote:
I need to test the jbyte version of Atomic::cmpxchg in the VM, but so
far it doesn't seem to be the case that any library code will actually
invoke it. At the top Java level there is no Atomic
On 08/19/2016 10:13 AM, David Holmes wrote:
>> Now it might be cleaner to ditch Java version from Unsafe, and make
>> native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short}
>> which would call relevant Atomic::cmpxchg-s.
>
> I tried commenting out the Java-ish version and defining o
On Aug 19, 2016, at 12:13 AM, David Holmes wrote:
>
> No idea where this is coming from or how I can disable it ??
This is controlled by CheckIntrinsics in the JVM, a diagnostic option always on.
It avoids accidentally expanding Java methods without the author's consent.
— John
Dear all,
please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164102
Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/
The countedLoop implementation would yield loops with wrong iteration counts if
start and end values around the fringes of the int value space wer
Looks good for now,
thanks!
/Claes
On 2016-08-19 09:55, Michael Haupt wrote:
Dear all,
please review this fix.
Bug: https://bugs.openjdk.java.net/browse/JDK-8164102
Webrev: http://cr.openjdk.java.net/~mhaupt/8164102/webrev.00/
The countedLoop implementation would yield loops with wrong itera
On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
On 08/19/2016 10:13 AM, David Holmes wrote:
Now it might be cleaner to ditch Java version from Unsafe, and make
native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short}
which would call relevant Atomic::cmpxchg-s.
I tried commenting o
On 08/19/2016 12:26 PM, David Holmes wrote:
> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
>> On 08/19/2016 10:13 AM, David Holmes wrote:
Now it might be cleaner to ditch Java version from Unsafe, and make
native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short}
which
Hi,
after the internal improvements in JDK-8164451, adding pre-generation of
zero
and identity forms turns out to be very trivial.
Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8164451
This removes runtime generation of 2 classes
On 08/19/2016 01:08 PM, Claes Redestad wrote:
> Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/
Looks good.
> This removes runtime generation of 2 classes from the test in
> JDK-8086045, leaving only 2 generated forms to deal with to get down
> to no(!) bytecode generation during
Hi Claes,
thumbs up.
Best,
Michael
> Am 19.08.2016 um 12:08 schrieb Claes Redestad :
>
> Hi,
>
> after the internal improvements in JDK-8164451, adding pre-generation of zero
> and identity forms turns out to be very trivial.
>
> Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01
Looks good.
Best regards,
Vladimir Ivanov
On 8/19/16 1:08 PM, Claes Redestad wrote:
Hi,
after the internal improvements in JDK-8164451, adding pre-generation of
zero
and identity forms turns out to be very trivial.
Webrev: http://cr.openjdk.java.net/~redestad/8164451/webrev.01/
Bug: https://b
On 19/08/2016 7:37 PM, Aleksey Shipilev wrote:
On 08/19/2016 12:26 PM, David Holmes wrote:
On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
On 08/19/2016 10:13 AM, David Holmes wrote:
Now it might be cleaner to ditch Java version from Unsafe, and make
native entry points like Unsafe_CompareAnd{E
Thanks Nadeesh. It's a good catch!
Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/8164366/01/webrev/
I also slightly modified comareTo(), not because there was an error in
it, but just to avoid thinking too much about possible overflow in
subtraction (of course, there can be
On 08/19/2016 03:03 PM, David Holmes wrote:
> On 19/08/2016 7:37 PM, Aleksey Shipilev wrote:
>> On 08/19/2016 12:26 PM, David Holmes wrote:
>>> On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
On 08/19/2016 10:13 AM, David Holmes wrote:
>> Now it might be cleaner to ditch Java version from U
I'm less comfortable with the compareTo change because it may make it
slower and that may have knock on effects. I think a comment saying
that both are bounded would be enough in compareTo()
Stephen
On 19 August 2016 at 13:52, Ivan Gerasimov wrote:
> Thanks Nadeesh. It's a good catch!
>
> Here'
> On 18 Aug 2016, at 17:55, Steve Drach wrote:
>
You might wanna create a temporary jar file if possible, just in case the
test somehow fails to clean things up.
>>>
>>> Unsure how to do that, or perhaps I don’t understand your request.
>>
>> I believe it’s possible to create a temp
Hi!
I'm trying out JEP 264: Platform Logging API and Service but can't get
it to work (or misunderstood something).
My understanding is that the JVM should use the provided LoggerFinder to
log its own messages. So when I start with "-verbose:gc" I expected the
message "Using G1" to go through my
On 19.08.2016 17:32, Stephen Colebourne wrote:
I'm less comfortable with the compareTo change because it may make it
slower and that may have knock on effects. I think a comment saying
that both are bounded would be enough in compareTo()
Okay. I reverted that change back then and added a comme
Hi Nicolai,
Log messages emitted by the JVM are not emitted through
the System.Logger API. JEP 264 is a pure Java API which
aims at replacing the sun.util.logging.PlatformLogger
implementation.
I believe what you are looking for is JEP 158
Unified JVM Logging [1]
best regards,
-- daniel
[1] h
Hi Daniel,
thanks for the quick reply. And you are of course right.
Luckily I don't care about the specific G1 message. After setting
everything up, I was looking for _anything_ that logs a message and that
was the first thing I came up with. Forgot the "platform classes" in the
first sentence.
Hi Nicolai,
On 19/08/16 16:05, Nicolai Parlog wrote:
On a tangent, I also wondered what would be the preferred way to log
from inside my code. Should I use System::getLogger directly?
Logger logger = System.getLogger("Application");
logger.log(Level.INFO, "Hello, World!");
so
Hi Nicolai,
On 19/08/16 16:21, Nicolai Parlog wrote:
Hi Daniel,
thanks for the quick reply. And you are of course right.
Luckily I don't care about the specific G1 message. After setting
everything up, I was looking for _anything_ that logs a message and that
was the first thing I came up wit
Hi!
I was very surprised how the syntax for private interface method
turned out. (I want to apologize in advance if this has been discussed
before. I searched but didn't find anything. And I know it's a bike
shed - still...)
I was going into a long explanation of what I thought were the reasons
Hi,
the generation of zero forms in JDK-8164451 was incorrect, since we
currently don't deal with constant placeholders in forms generated by
the jlink plugin. While the zero constants might be something we can
special-case, for now I have to back out the pre-generation of the zero
forms.
w
I agree with Alexey it should be possible to do this under the covers of
existing Unsafe methods.
Paul.
> On 19 Aug 2016, at 06:29, Aleksey Shipilev wrote:
>
> On 08/19/2016 03:03 PM, David Holmes wrote:
>> On 19/08/2016 7:37 PM, Aleksey Shipilev wrote:
>>> On 08/19/2016 12:26 PM, David Holmes
> On 19 Aug 2016, at 08:52, Claes Redestad wrote:
>
> Hi,
>
> the generation of zero forms in JDK-8164451 was incorrect, since we currently
> don't deal with constant placeholders in forms generated by the jlink plugin.
> While the zero constants might be something we can special-case, for no
FYI I don't think java.util.concurrent has any plans for sub-int-sized
atomics. We would use it if we added an AtomicByteArray, but that probably
won't happen (users can just use VarHandle directly!)
On 19/08/2016 11:29 PM, Aleksey Shipilev wrote:
On 08/19/2016 03:03 PM, David Holmes wrote:
On 19/08/2016 7:37 PM, Aleksey Shipilev wrote:
On 08/19/2016 12:26 PM, David Holmes wrote:
On 19/08/2016 5:40 PM, Aleksey Shipilev wrote:
On 08/19/2016 10:13 AM, David Holmes wrote:
Now it might be
> On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote:
>
>
>> On Aug 13, 2016, at 1:20 AM, Peter Levart wrote:
>>
>> Hi Mandy,
>>
>> On 08/13/2016 01:55 AM, Mandy Chung wrote:
On Aug 8, 2016, at 6:25 PM, Kim Barrett
wrote:
full:
http://cr.openjdk.java.net/~kbarrett/8156
Hi, Fred
Thanks for having a look. Good questions...
On 08/17/2016 02:28 PM, Frederic Parain wrote:
hotspot/src/share/vm/prims/stackwalk.cpp:
230 if (!expressions &&
231 values->at(i)->type() == T_INT &&
232 values->int_at(i) == 0 && // empty first slot of long?
233
> On Aug 19, 2016, at 4:09 PM, Kim Barrett wrote:
>
>> On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote:
>>
>>
>>> On Aug 13, 2016, at 1:20 AM, Peter Levart wrote:
>>>
>>> Hi Mandy,
>>>
>>> On 08/13/2016 01:55 AM, Mandy Chung wrote:
> On Aug 8, 2016, at 6:25 PM, Kim Barrett
> wrote:
> On Aug 19, 2016, at 7:54 PM, Mandy Chung wrote:
>
>
>> On Aug 19, 2016, at 4:09 PM, Kim Barrett wrote:
>>
>>> On Aug 13, 2016, at 4:07 PM, Mandy Chung wrote:
>>>
>>>
On Aug 13, 2016, at 1:20 AM, Peter Levart wrote:
Hi Mandy,
On 08/13/2016 01:55 AM, Mandy Chung
32 matches
Mail list logo
