Hi,
I monitored memory usage, below are the details.
Heap usage :- 857mb
Virtual memory:- 12.6gb
-Xmx set to 4gb.
I have taken virtual and heap memory usage when Java spawns sub
processes.
Thanks & Regards,
Manjunath
On 15 Sep 2016 4:17 p.m., <core-libs-dev-requ...@openjdk.java.net> wrote:
Send core-libs-dev mailing list submissions to
core-libs-dev@openjdk.java.net
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
or, via email, send a message with subject or body 'help' to
core-libs-dev-requ...@openjdk.java.net
You can reach the person managing the list at
core-libs-dev-ow...@openjdk.java.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of core-libs-dev digest..."
Today's Topics:
1. Re: RFC: System.console().encoding() (Xueming Shen)
2. Re: RFC: System.console().encoding() (Dawid Weiss)
3. Re: RFC: System.console().encoding() (Claes Redestad)
4. Re: RFR: JDK-8134373: explore potential uses of convenience
factories within the JDK (Jonathan Bluett-Duncan)
5. Re: Reg - Sub Process creation from java takes more time
(e...@zusammenkunft.net)
6. Re: RFC: System.console().encoding() (Jochen Theodorou)
7. Re: RFC: System.console().encoding() (Dawid Weiss)
8. Re: RFR: JDK-8134373: explore potential uses of convenience
factories within the JDK (Pavel Rappo)
----------------------------------------------------------------------
Message: 1
Date: Thu, 15 Sep 2016 00:06:05 -0700
From: Xueming Shen <xueming.s...@oracle.com>
To: core-libs-dev@openjdk.java.net
Subject: Re: RFC: System.console().encoding()
Message-ID: <57da485d....@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
-1 :-)
Console is supposed to be a "char/String" based class, "encoding" really
should
have no business here in its api. Simply for some implementation convenience
is really not a good reason to add such a public method.
That said, I would be fine to have such informative info in the system
properties,
together with its siblings, file,encoding and another "supposed to be
private"
property sun.jnu.encoding.
sherman
On 9/14/16, 11:42 PM, Aleksey Shipilev wrote:
Hi,
Claes pointed out that our own reflective hacks to figure out console
encoding do not work anymore [1]. But, we need the console encoding for
reliably printing on the console from within different sources. Note
that you would normally just use System.console() and its PrintWriter,
but reality is a bit more complicated, and sometimes you need to write
the plain char stream directly into the byte[]-accepting methods,
encoding on your own.
So, my question: should we, in the light of extended Jigsaw-solving
crunch, provide the public Console.encoding() method that would return
the console charset?
Thanks,
-Aleksey
[1]
http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
------------------------------
Message: 2
Date: Thu, 15 Sep 2016 09:21:01 +0200
From: Dawid Weiss <dawid.we...@gmail.com>
To: Xueming Shen <xueming.s...@oracle.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: RFC: System.console().encoding()
Message-ID:
<cam21rt8rhp3zbokmqtfr5j959sb_jjvf-awyn_unhhu2324...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Console is supposed to be a "char/String" based class, "encoding" really
should have no business here in its api.
While I agree with your concerns about the functional side of the API,
I disagree about this method having no practical use. I can give you a
concrete example. The use case that we had was to check whether the
"terminal" (console) would be able to handle non-ASCII characters. A
Writer doesn't tell you anything. An encoding does provide at least
some confidence that certain characters will be translated properly --
if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't
get displayed for sure. This doesn't mean 100% confidence in actual
glyph rendering of course, but it's a cheap and safe sanity check of
the terminal's capabilities.
An (undocumented) proprietary property? Sure, but I really don't see
the reason why this shouldn't be in the API, unless you know of
terminals that handle Unicode-based streams directly (in which case
the encoding method would simply return UTF32).
Dawid
------------------------------
Message: 3
Date: Thu, 15 Sep 2016 10:18:29 +0200
From: Claes Redestad <claes.redes...@oracle.com>
To: core-libs-dev@openjdk.java.net
Subject: Re: RFC: System.console().encoding()
Message-ID: <57da5955.4070...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
+1
Won't be enough, though, since in JMH it appears you're also getting
the encoding from System.out (java.io.PrintStream) via reflective
hacks.
/Claes
On 2016-09-15 08:42, Aleksey Shipilev wrote:
Hi,
Claes pointed out that our own reflective hacks to figure out console
encoding do not work anymore [1]. But, we need the console encoding for
reliably printing on the console from within different sources. Note
that you would normally just use System.console() and its PrintWriter,
but reality is a bit more complicated, and sometimes you need to write
the plain char stream directly into the byte[]-accepting methods,
encoding on your own.
So, my question: should we, in the light of extended Jigsaw-solving
crunch, provide the public Console.encoding() method that would return
the console charset?
Thanks,
-Aleksey
[1]
http://mail.openjdk.java.net/pipermail/jmh-dev/2016-September/002330.html
------------------------------
Message: 4
Date: Thu, 15 Sep 2016 09:52:47 +0100
From: Jonathan Bluett-Duncan <jbluettdun...@gmail.com>
To: Patrick Reinhart <patr...@reini.net>, Stuart Marks
<stuart.ma...@oracle.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: RFR: JDK-8134373: explore potential uses of convenience
factories within the JDK
Message-ID:
<capmys85-dqhvwyaomn+izbqpkzdgoa4ju4wppdupim-3ub1...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Thanks Patrick!
Stuart, would you be happy to sponsor this change?
If anyone else has any thoughts regarding this change, then I'm all ears.
Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373
Rationale for changes:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
September/043484.html
Kind regards,
Jonathan
On 14 September 2016 at 21:55, Patrick Reinhart <patr...@reini.net> wrote:
Hi Jonathan,
Here are your changes in a webrev:
http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00
-Patrick
Am 13.09.2016 um 14:45 schrieb Patrick Reinhart <patr...@reini.net>:
Hi Jonathan,
On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote:
Hi Patrick,
Thank you very much for the offer to hold my patch for me!
No problem.
Is it common practice to send patches to others using PGP?
No, this is my personal setting.
Kind regards,
Jonathan
On 12 September 2016 at 21:08, Patrick Reinhart <patr...@reini.net> wrote:
Hi Jonathan,
As I just also wanted to help some more clean-up in the JDKs final phase,
I
could offer you to hold that patch. Just send it to me and I will prepare
the webrev for you?.
-Patrick
-Patrick
------------------------------
Message: 5
Date: Thu, 15 Sep 2016 11:01:01 +0200
From: <e...@zusammenkunft.net>
To: "core-libs-dev@openjdk.java.net" <core-libs-dev@openjdk.java.net>
Subject: Re: Reg - Sub Process creation from java takes more time
Message-ID: <57da634c.c336c20a.19b0c.b...@mx.google.com>
Content-Type: text/plain; charset="utf-8"
Hello,
Do you monitor heap usage and virtual memory size of your Java process? I
would look out for increase (which causes slower for tines).
Also it is generally a good idea to turn on GC logging and look into it if
a java process degregades over time
Gruss
Bernd
Just BTW: I think Java would not be the right tool to spawn and control
sich a high number of external processes. Maybe it would be better to hand
that off to a more native component.
--
http://bernd.eckenfels.net
Von: Manjunath SV
------------------------------
Message: 6
Date: Thu, 15 Sep 2016 12:05:04 +0200
From: Jochen Theodorou <blackd...@gmx.org>
To: core-libs-dev@openjdk.java.net
Subject: Re: RFC: System.console().encoding()
Message-ID: <57da7250.9020...@gmx.org>
Content-Type: text/plain; charset=utf-8; format=flowed
On 15.09.2016 09:21, Dawid Weiss wrote:
Console is supposed to be a "char/String" based class, "encoding" really
should have no business here in its api.
While I agree with your concerns about the functional side of the API,
I disagree about this method having no practical use. I can give you a
concrete example. The use case that we had was to check whether the
"terminal" (console) would be able to handle non-ASCII characters. A
Writer doesn't tell you anything. An encoding does provide at least
some confidence that certain characters will be translated properly --
if your encoding is US-ASCII or ISO8859-1 then Polish diacritics won't
get displayed for sure. This doesn't mean 100% confidence in actual
glyph rendering of course, but it's a cheap and safe sanity check of
the terminal's capabilities.
out of curiosity... what will you do if you find the encoding lacking
what you need?
bye Jochen
------------------------------
Message: 7
Date: Thu, 15 Sep 2016 12:17:26 +0200
From: Dawid Weiss <dawid.we...@gmail.com>
To: Jochen Theodorou <blackd...@gmx.org>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: RFC: System.console().encoding()
Message-ID:
<CAM21Rt-NF6nuxpJMhmqh--pA-LTO6zmX0x5K0f7=rrwj_at...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
out of curiosity... what will you do if you find the encoding lacking what
you need?
Oh, display a warning. Helps to figure out where those "???"
characters are coming from...
Naive, I know. But it's the best one can do and it works (most of the time).
D.
------------------------------
Message: 8
Date: Thu, 15 Sep 2016 11:46:17 +0100
From: Pavel Rappo <pavel.ra...@oracle.com>
To: Jonathan Bluett-Duncan <jbluettdun...@gmail.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
Subject: Re: RFR: JDK-8134373: explore potential uses of convenience
factories within the JDK
Message-ID: <fd16b50e-cc8a-4d49-94f2-80e16531b...@oracle.com>
Content-Type: text/plain; charset=utf-8
Hi,
I have had a look at the change. It looks good.
Retrofitting Collections.unmodifiableXXX/Arrays.asList with Convenience
Factory
Methods requires extra carefulness as the factory methods are stricter than
any
of those. Not only do they provide unconditional non-modifiability [0], they
also do not tolerate `null` elements.
It looks like you took all that into account.
Tiny little comments and suggestions.
1. It might be the case we no longer need this [1]:
finderList.forEach(Objects::requireNonNull);
as the List.of does the same thing for free. Though it might be okay to
leave it
as an explicit check.
Also, could you please fix a typo here (the same file):
* will be propogated to the caller of the resulting module finder's
^
2. An interesting question (though it's a completely different issue) is
whether
or not the `cookieHeader` list in the map should also be unmodifiable [2]?
3. Could you please also fix the same (copy-pasted?) typo in FileTreeWalker?
if {@code options} is {@ocde null} or the options
^^
4. Please remove this line from the ZoneRules constructor's javadoc:
@return the zone rules, not null
5. Maybe we should revisit javadoc on those fields in [3]:
This <code>List</code> is {@linkplain Collections#unmodifiableList(List)
unmodifiable}.
Since it's no longer the case.
6. I couldn't find any evidence that `resolverFields` might contain `null`.
Am I missing a javadoc or a line of code? Maybe we should talk to java.time
folks to see if it's the case?
7. Try to not make lines longer than they were before: 80 characters. Unless
it's really needed.
Thanks,
-Pavel
------------------------------------------------------------
--------------------
[0] Compare List.of().remove(new Object()) with
Collections.emptyList().remove(new
Object())
[1] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
webrev.00/src/java.base/share/classes/java/lang/module/
ModuleFinder.java.sdiff.html
[2] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
webrev.00/src/java.base/share/classes/java/net/CookieManager.java.sdiff.html
[3] http://cr.openjdk.java.net/~reinhapa/reviews/8134373/
webrev.00/src/java.base/share/classes/java/util/
ResourceBundle.java.sdiff.html
On 15 Sep 2016, at 09:52, Jonathan Bluett-Duncan <jbluettdun...@gmail.com>
wrote:
Thanks Patrick!
Stuart, would you be happy to sponsor this change?
If anyone else has any thoughts regarding this change, then I'm all ears.
Bug link: https://bugs.openjdk.java.net/browse/JDK-8134373
Rationale for changes:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-
September/043484.html
Kind regards,
Jonathan
On 14 September 2016 at 21:55, Patrick Reinhart <patr...@reini.net> wrote:
Hi Jonathan,
Here are your changes in a webrev:
http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.00
-Patrick
Am 13.09.2016 um 14:45 schrieb Patrick Reinhart <patr...@reini.net>:
Hi Jonathan,
On 2016-09-13 02:13, Jonathan Bluett-Duncan wrote:
Hi Patrick,
Thank you very much for the offer to hold my patch for me!
No problem.
Is it common practice to send patches to others using PGP?
No, this is my personal setting.
Kind regards,
Jonathan
On 12 September 2016 at 21:08, Patrick Reinhart <patr...@reini.net>
wrote:
Hi Jonathan,
As I just also wanted to help some more clean-up in the JDKs final
phase, I
could offer you to hold that patch. Just send it to me and I will prepare
the webrev for you?.
-Patrick
-Patrick
End of core-libs-dev Digest, Vol 113, Issue 53
**********************************************
