Hello.
JDK8 Linux build has COMPOUND_TEXT charset, but it seems it's missing on
JDK11 Linux build.
I checked Bug DB, I could not find out the reason why COMPOUND_TEXT
charset was missing.
Could you port COMPOUND_TEXT charset from JDK8 to JDK11 ?
Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.
8205184: Delegating Iterator implementations that don't delegate
forEachRemaining()
http://cr.openjdk.java.net/~martin/webrevs/jdk/delegate-forEachRemaining/
https://bugs.openjdk.java.net/browse/JDK-8205184
JDK 11 draws nigh.
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.html
8202422: value of 'sizeCtl' in ConcurrentHashMap varies with the
constructor called
http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/sizeCtl/index.html
Thanks Paul for taking some time and thinking about it.
I will make the change you have mentioned and send the patch again.
Regards,
Vivek
-Original Message-
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Thursday, June 21, 2018 3:32 PM
To: Deshpande, Vivek R
Cc:
Aha, I wonder if it's configured with the APR native library for SSL. I
will check out that and those things.
Thanks
Oliver
On 21 June 2018 at 21:43:24, Bernd Eckenfels (e...@zusammenkunft.net) wrote:
Are you using any native libraries in this VM, is there a hs_err or System
core file? Can you
Hi Vivek,
This looks better. I thought a bit more about NaNs. I am concerned about edge
case performance regressions if the first two values are NaNs (with the same
bit pattern). Here’s a patch on top of your patch that compares the raw bits
for float/double elements. If you are ok with this
Hi Bernd,
Thanks for your comments.
On 06/20/2018 05:05 PM, Bernd Eckenfels wrote:
Just a FYI under Linux when you read from urandom the Linux kernel will always
XOR with random bytes generated with x64 rdrand instruction
(arch_get_random_lomg() - if supported). Since it is a XOR it does not
* Tony Printezis:
> There are a few obvious ways to mitigate this, e.g., cause a Full GC /
> concurrent GC cycle at regular intervals. However, the best solution IMHO
> is to explicitly free any direct buffers that are still in the cache when a
> thread exits.
Why is this safe? Couldn't these
Are you using any native libraries in this VM, is there a hs_err or System core
file? Can you run „ldd“ on the java launcher binary. Can you try a OpenJDK
binary distribution independent of the OS compiled version?
Gruss
Bernd
--
http://bernd.eckenfels.net
From:
This looks good to me AFAICT.
Mandy
On 6/19/18 5:08 PM, Paul Sandoz wrote:
Hi,
Please review the following fix to ensure method references to
VarHandle signature polymorphic methods are supported at runtime
(specifically the method handle to a signature polymorphic method can
be loaded from
Looks fine.
Mandy
On 6/14/18 10:41 AM, Paul Sandoz wrote:
Hi,
Please review an update to the specifications of LambdaMetafactory
and SerializedLambda to clarify that the identity of function objects
is unpredictable. A similar (informational) clarification was made to
the language
+1
> On Jun 14, 2018, at 2:41 PM, Paul Sandoz wrote:
>
> Hi,
>
> Please review an update to the specifications of LambdaMetafactory and
> SerializedLambda to clarify that the identity of function objects is
> unpredictable. A similar (informational) clarification was made to the
> language
Gentle reminder,
Paul.
> On Jun 14, 2018, at 10:41 AM, Paul Sandoz wrote:
>
> Hi,
>
> Please review an update to the specifications of LambdaMetafactory and
> SerializedLambda to clarify that the identity of function objects is
> unpredictable. A similar (informational) clarification was
Hi Roger,
Are the three versions of listProcFD() identical? Is so, could this method be
put in test/lib/jdk/test/lib/util/FileUtils.java instead?
Thanks,
Brian
On Jun 21, 2018, at 11:59 AM, Roger Riggs wrote:
> Please review a test improvement to avoid spurious errors caused by
>
On 6/21/18 11:59 AM, Roger Riggs wrote:
Please review a test improvement to avoid spurious errors caused by
concurrent changes in open files during the test.
The other existing conditions in the test are sufficient to verify the
correct finalize behavior.
Some additional diagnostics are
Please review a test improvement to avoid spurious errors caused by
concurrent changes in open files during the test.
The other existing conditions in the test are sufficient to verify the
correct finalize behavior.
Some additional diagnostics are added and the tests removed from the
problem
Hi Paul
The folding of if/else is the right way in this patch which I missed in earlier
webrev.
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.03/
I think I would keep the same earlier path if both the values are NaN.
Thanks.
Regards,
Vivek
From: Paul Sandoz
Peter,
The changes to TestMaxCachedBufferSize.java look fine. One point though:
Why do you need the TmpDirectBuffersReclamation.java test? In
TestMaxCachedBufferSize.java you just call checkDirectBuffers(0, 0); after
you the main thread calls join() on the workers?
Tony
—
Tony Printezis |
On 06/21/2018 07:01 PM, Tony Printezis wrote:
I’m trying exactly that. :-)
Sorry, I didn't know. Here's my attempt:
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.07/
I also added @run main/othervm to TempDirectBuffersReclamation test.
Peter
—
Tony Printezis
I’m trying exactly that. :-)
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On June 21, 2018 at 12:59:58 PM, Peter Levart (peter.lev...@gmail.com)
wrote:
On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
On 06/21/2018 06:17 PM, Tony Printezis wrote:
I was saying: I looked at TestMaxCachedBufferSize and, unfortunately,
I don’t think the test makes a lot of sense right now as it checks the
number / size of direct buffers after all the threads terminate and,
with this change, that should
Yes makes sense. Good catch :)
Thanks :)
Regards,
Vivek
-Original Message-
From: Ivan Gerasimov [mailto:ivan.gerasi...@oracle.com]
Sent: Wednesday, June 20, 2018 5:24 PM
To: Deshpande, Vivek R
Cc: Paul Sandoz ; core-libs-dev@openjdk.java.net
Subject: Re: RFR(S): 8205194: Improve the
Hi Paul,
Sorry for the delay in responding to this -- holiday and then an urgent
bug fix intervened . . .
On 08/06/18 01:42, Paul Sandoz wrote:
> Sandhya gave an overview to a few of us Oracle folks. I agree with
> what Sandhya says regarding the API, a small surface, and on pursuing
> an unsafe
…and I also hadn’t attached the test. Sorry, I’m clearly very distracted
today!
—
Tony Printezis | @TonyPrintezis | tprinte...@twitter.com
On June 21, 2018 at 12:17:57 PM, Tony Printezis (tprinte...@twitter.com)
wrote:
(I unfortunately pressed Send accidentally; apologies)
I was saying:
(I unfortunately pressed Send accidentally; apologies)
I was saying: I looked at TestMaxCachedBufferSize and, unfortunately, I
don’t think the test makes a lot of sense right now as it checks the number
/ size of direct buffers after all the threads terminate and, with this
change, that should
Peter,
Attached TerminatingThreadLocalTest.java. Let me know what you think (and
feel free to modify it / discard it if you don’t like it!).
Re: The test for the max cached buffer size is:
test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java. I looked at it and,
unfortunately,
—
Tony Printezis
On 06/21/2018 05:53 PM, Peter Levart wrote:
Hi,
On 06/21/2018 09:42 AM, Alan Bateman wrote:
On 20/06/2018 15:08, Peter Levart wrote:
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Yes, I think this looks good.
Do we need a test which
Hi,
On 06/21/2018 09:42 AM, Alan Bateman wrote:
On 20/06/2018 15:08, Peter Levart wrote:
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Yes, I think this looks good.
Do we need a test which proves that cached direct buffers are
released
Hi Thomas,
Unfortunately not, that was /var/log/tomcat8/catalina.out, a snippet from
just before to afterwards when I restarted is below. Everything after
'free(): corrupted unsorted chunks', from 'Note: Picked up
JDK_JAVA_OPTIONS' on was only logged on restart. The warnings are normal.
The
On Tue, Jun 19, 2018 at 6:06 AM, David Lloyd wrote:
> It may be confusing (to some, I guess) but it is consistent: the
> ThreadLocal subclass author has absolute control over how the value is
> presented to the user. Adding compute() or many of the other
> suggested variants will break that
Hi Oliver,
Is there a stack trace on stderr?
Thanks, Thomas
On Thu, Jun 21, 2018 at 1:59 PM, Oliver Kohll wrote:
> Hi,
>
> I'm a Java developer getting a crash and error message 'free(): corrupted
> unsorted chunks' in the log. this sounds like it could be a low level issue
> in the core
Hi,
I'm a Java developer getting a crash and error message 'free(): corrupted
unsorted chunks' in the log. this sounds like it could be a low level issue
in the core Java libraries so I'm posting here, but if it would be better
in another list (or even a different community) please let me know.
On 06/20/2018 04:24 PM, Tony Printezis wrote:
Hey Peter,
I had written a test to test my version of the exit hooks. I can
easily rework it to work with yours. Interested?
Of course. Just give what you got. I can modify it as needed.
To check that the native buffers are reclaimed
Hi Bernard,
Yes, your fix is good but would be nicer if the comment in line 733 is modified
as well since it might be misleading.
> 733 /* On AIX, readdir() returns EBADF ...
I only have Linux machines to test. But I suggest that your patch being merged
soon as the deprecated use breaks
Yes, the proposal is to create a new module outside the JDK.
I was originally responding to your suggestion of not including these
charsets in java.base.
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053316.html
"Separately, I think we should start a discussion here about
Thanks John!
On 21/06/2018 6:15 AM, John Rose wrote:
Good; I like the care to distinguish "nested" classes (using the
word "enclosing") from the newer concept of "nests" and "nestmates",
as well as the careful framing of how stuff bubbles up from the classfile.
(Kudos to Alex!)
Yes this is
Thanks Paul!
David
On 21/06/2018 3:43 AM, Paul Sandoz wrote:
On Jun 19, 2018, at 10:25 PM, mandy chung wrote:
The javadoc update looks good to me.
Same here, +1
Paul.
Hi Alan,
Some context might be helpful here:
The real JFR API is located in module jdk.jfr and the API handle there is this
class jdk.jfr.Event [1]
There are multiple reasons for choosing an class as the API instead of an
interface - most of them are driven by implementation (in the VM) and
Hi Karen,
On 21/06/2018 7:42 AM, Karen Kinnear wrote:
Looks good.
Thanks. Unfortunately there were a few more minor edits "overnight".
Everything updated in place (apologies as I wanted to include a simple
patch but overwrote things before realising I now had no means to do so.)
Summary:
Thanks Naoto, Roger for the review. Made the suggested changes and
pushed to the repo.
Regards,
Nishit Jain
On 21-06-2018 00:23, Roger Riggs wrote:
Hi Nishit,
Looks ok
My only comment would be to put the relative path to the
language-subtag-registry.txt in a private static final constant
to
On 20/06/2018 18:59, Erik Gahlin wrote:
:
Also all the methods are empty which makes me wonder if they should
be abstract (as the class is abstract) or whether it should be an
interface.
Abstract is needed to prevent user from instantiating the class.
The methods need to have a body,
On 20/06/2018 15:08, Peter Levart wrote:
Like the following?
http://cr.openjdk.java.net/~plevart/jdk-dev/DBBCache_Cleanup/webrev.05/
Yes, I think this looks good.
Do we need a test which proves that cached direct buffers are released
when thread exits or would a unit test for
42 matches
Mail list logo
