Added core-libs-dev. Sorry for the crosspost.
On Wed, Apr 1, 2015 at 10:35 AM, Thomas Stüfe thomas.stu...@gmail.com
wrote:
Hi,
please review this tiny change. It fixes a build error on MacOS when
building jdk without optimization.
bug: https://bugs.openjdk.java.net/browse/JDK-8074547
Am 01.04.2015 um 13:48 schrieb Alan Bateman alan.bate...@oracle.com:
On 01/04/2015 12:24, Robert Stupp wrote:
Is it because of pausing GC otherwise?
Yes, GC and also that a Socket write is a potentially blocking operation.
Some VMs do have a way of pinning objects in the heap (beyond
Hi,
jdk/src/solaris/native/java/net/SocketOutputStream.c always copy data from the
given byte[] to a temporary stack/heap buffer.
Wouldn’t it be sufficient to just use a pointer into the byte[] and directly
call NET_Send with that pointer?
—
Robert Stupp
@snazy
Is it because of pausing GC otherwise?
Am 01.04.2015 um 13:21 schrieb Robert Stupp sn...@snazy.de:
Hi,
jdk/src/solaris/native/java/net/SocketOutputStream.c always copy data from
the given byte[] to a temporary stack/heap buffer.
Wouldn’t it be sufficient to just use a pointer into the
Hi Frank,
On Apr 1, 2015, at 6:46 AM, Frank Yuan frank.y...@oracle.com wrote:
Hi Lance
Thank you for your comments!
I have already added/updated the comments as your suggestion.
I see them in the webrev below but were not in webrev.01 which is what I looked
at yesterday
For
On 01/04/2015 12:24, Robert Stupp wrote:
Is it because of pausing GC otherwise?
Yes, GC and also that a Socket write is a potentially blocking
operation. Some VMs do have a way of pinning objects in the heap (beyond
JNI critical sections) but it is not assumed here.
If you do socket I/O
On 01/04/2015 13:37, Robert Stupp wrote:
:
Just want to understand ”the magic” here (sure, NIO is the way to go)…
Where’s the ”trick” to avoid GC pauses for socketWrite0 and similar
methods?
Is it something hard coded like ”if JNI method is from jdk source tree”?
AFAIK there’s always a safe
Hello Thomas,
[removed jdk9-dev]
My take is that, there is a makefile oversight lurking somewhere wrt.
macosx, and
is likely to be fixed by fix for 8074840, the review discussion is here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032614.html
So for now lets put this
Hi Kumar,
ok, I'll wait. I see that Mikael did empty out ergo_i586.c for MacOsX
completely, which seems ok to me.
It would be nice to solve this soon as this is a constant error source for
our MacOS slowdebug builds.
Kind Regards, Thomas
On Wed, Apr 1, 2015 at 3:31 PM, Kumar Srinivasan
The JDK 8 documentation did not include any documentation on the new tags
(e.g., @apiNote, @implSpec and @implNote). It's neither here [1] nor there
[2], but they should be.
Can anyone look into this for 9 (or even fix 8)? The absence of
documentation is probably why they haven't seen widespread
On 01/04/2015 16:47, Paul Benedict wrote:
The JDK 8 documentation did not include any documentation on the new tags
(e.g., @apiNote, @implSpec and @implNote). It's neither here [1] nor there
[2], but they should be.
Can anyone look into this for 9 (or even fix 8)? The absence of
documentation
On Apr 1, 2015, at 1:56 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/
https://bugs.openjdk.java.net/browse/JDK-8057967
Impressive work.
Question: How
On 2/04/2015 3:22 AM, Mikael Vidstedt wrote:
New webrev available here:
http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.02/webrev/
Changes include:
* Excluded ergo_i586.c in the makefile on macosx instead of using
ifdef-style exclusion
Good.
* Updated to fix a newly introduced
New webrev available here:
http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.02/webrev/
Changes include:
* Excluded ergo_i586.c in the makefile on macosx instead of using
ifdef-style exclusion
* Updated to fix a newly introduced (currently silenced) warning in
Looks really clean and simple.
Some minor issues.
1)
Would it possible to add a connect timeout parameter.
builder.setConnectTimeout(long timeout, TimeUnit unit)
For some reason it was left out of the javax.websocket API. And working
around it is a serious PITA.
2)
Rename Websocket to
On 03/31/2015 03:35 AM, Martin Buchholz wrote:
Thanks, Peter.
I've started making my way through these changes.
It's too bad there's so much complexity here, but I can't come up with
a simpler solution either.
So we will probably submit something based on your latest webrev.
I've collected
CoreLibraries.gmk: glad you caught the ergo_i586.c.
That should also address: JDK-8074547
Looks good and Thanks!
Kumar
On 4/1/2015 10:22 AM, Mikael Vidstedt wrote:
New webrev available here:
http://cr.openjdk.java.net/~mikael/webrevs/8074840/webrev.02/webrev/
Changes include:
* Excluded
Hi all,
Please review this minor change which remove a dead code in
isLeapYear(long prolepticYear) method of
java/time/chrono/HijrahChronology.java.
Bug: https://bugs.openjdk.java.net/browse/JDK-8076441
Webrev: http://cr.openjdk.java.net/~rriggs/hadeesh-tv-8076441/
--
Thanks and Regards,
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/hotspot/
http://cr.openjdk.java.net/~vlivanov/8057967/webrev.00/jdk/
https://bugs.openjdk.java.net/browse/JDK-8057967
HotSpot JITs inline very aggressively through CallSites. The
optimistically treat CallSite target as constant, but record
19 matches
Mail list logo
