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
**********************************************
