Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes()
in MemberName?
Otherwise, looks fine.
Best regards,
Vladimir Ivanov
On 8/9/16 8:34 AM, Claes Redestad wrote:
Hi,
please review this patch to replace reflection calls into
java.lang.invoke from GenerateJLIClassesPlugin
MemberName defines the implementation of JavaLangInvokeAccess for some reason,
so that's unfortunately necessary.
/Claes
Vladimir Ivanov skrev: (9 augusti 2016 19:00:36
CEST)
>Why did you put generateDMHClassBytes()/generateConcreteBMHClassBytes()
>
>in
MemberName defines the implementation of JavaLangInvokeAccess for some
reason, so that's unfortunately necessary.
Oh, I see. I suggest to move the whole thing to MethodHandleImpl then.
It was exposing MemberName internals before your change, but it isn't
anymore.
Best regards,
Vladimir Ivanov
No, I haven't considered that. Thank you, Mandy. Good tip. And I see that
file also contains JAVA_FULL_VERSION, whose value is identical to the
-fullversion option output.
Cheers,
Paul
On Tue, Aug 9, 2016 at 11:40 AM, Mandy Chung wrote:
>
> > On Aug 8, 2016, at 8:51
This is nice in theory but has a number of drawbacks. First of all the common
pool is not very easy to configure. It takes the available CPUs and if you run
more than one VM you overcommit. Secondly different strategies to deal with
longrunning or blocked jobs, with priority inheritance, with
If you are only looking for the version, would JAVA_VERSION satisfy your need?
JAVA_FULL_VERSION is only present in JDK and JRE image but not custom image
since the property is supplied by the jdk build.
Mandy
> On Aug 9, 2016, at 9:49 AM, Paul Benedict wrote:
>
> No, I
Hi
Please review the following webrev which combines:
8161444 VarHandles should provide access bitwise atomics
8162107 Add acquire/release variants for getAndSet and getAndAdd
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8161444-vhs-bitwise-atomics/webrev/
On 10/08/2016 2:37 AM, Christian Schulte wrote:
Am 08/08/16 um 02:04 schrieb Brian Goetz:
If a library wants to offer a customization point where it accepts an
FJPool, clients should be encouraged to pass the common pool (and the
common pool is a good default) unless there are specific reasons
My Windows 10 is English, but I want the java command to show Chinese
help screen temporarily.
I've tried "set LANG", chcp, "control intl.cpl,, /f:" but none works.
Thanks
Max
Hi Max,
Does setting -Duser.country=CN work for you? (I don't remember what the
correct name for China should be, but setting that to US forces java to
print the help message in English)
- Kris
On Tue, Aug 9, 2016 at 6:25 PM, Weijun Wang wrote:
> My Windows 10 is
Am 08/09/16 um 19:04 schrieb e...@zusammenkunft.net:
> This is nice in theory but has a number of drawbacks. First of all the
> common pool is not very easy to configure. It takes the available CPUs
> and if you run more than one VM you overcommit. Secondly different
> strategies to deal with
> On Aug 9, 2016, at 8:34 AM, Claes Redestad wrote:
>
> Hi,
>
> please review this patch to replace reflection calls into java.lang.invoke
> from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink via
> JavaLangInvokeAccess/SharedSecrets.
>
>
Hello!
Two classes from java.io package may experience the integer overflow
problem in their read() methods.
Would you please help review the obvious fix?
The regression tests are @ignored by default, as they require 4+ GB of
the heap to run.
BUGURL:
Hi Max,
Java's default locale follows the default UI Language on Windows. So
your Windows has to have Chinese UI package installed and selected as
the default UI language. I don't have Windows 10 at hand, but Windows
used to be capable of downloading/installing UI language packs on
certain
Hi Kris
Yes, it works, with -Duser.language.
Unfortunately, I am looking for a way to change the default/initial
locale, and then using these system properties to change the effective
locale again. :-)
Precisely, there is a test using grep to match warning messages and on a
Chinese Windows
Hi John,
JDK-8061177 [1] has been resolved as a duplicate of
JDK-8065756 [2] which is still open.
The correct action for this one might be to leave the
test in the problem list but change the bug ID.
The rest looks good to me - even though
two of these test have been fixed by either adding
Hi,
change to enable DMH pre-generation caused a subtle change in the
stacktrace, which caused this test to fail.
Please review this patch which reverts the stackframe to look like
before for non-pregenerated DMHs, while also updating the test to accept
pregenerated DMHs.
To verify this
On 08/09/2016 08:31 AM, Tagir F. Valeev wrote:
> --- a/src/java.base/share/classes/java/util/stream/Collectors.java Tue
> Aug 02 07:19:06 2016 +0530
> +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Tue
> Aug 09 11:47:20 2016 +0700
> @@ -295,7 +295,12 @@
>
Hello, Aleksey!
Thank you for review.
AS> Good trick, but does it work properly with the sets that care about the
AS> add order, e.g. LinkedHashSet? I guess our saving grace here is
AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter
AS> order without violating the API
On 08/09/2016 10:19 AM, Tagir F. Valeev wrote:
> AS> Good trick, but does it work properly with the sets that care about the
> AS> add order, e.g. LinkedHashSet? I guess our saving grace here is
> AS> Collector.toSet() is declared UNORDERED, so we can disturb the encounter
> AS> order without
Hi Kim,
On 2016-08-09 03:25, Kim Barrett wrote:
On Aug 8, 2016, at 8:16 AM, Per Liden wrote:
Hi Kim,
On 2016-08-01 20:47, Kim Barrett wrote:
This updated webrev addresses concerns about the performance of the VM
API used by the reference processor thread in the
On 08/09/2016 12:09 AM, Paul Sandoz wrote:
>> On 4 Aug 2016, at 12:02, Claes Redestad
>> wrote:
>> Hi,
>>
>> I'd like to sponsor this bug fix provided by Tomáš Hůrka to remove
>> a new and dup left behind in generated accessor methods after
>> moving these to use
On 2016-08-08 15:50, Aleksey Shipilev wrote:
On 08/08/2016 04:18 PM, Claes Redestad wrote:
http://cr.openjdk.java.net/~redestad/8163369/webrev.02/
Looks good.
-Aleksey
Thanks!
Pushed.
/Claes
On 2016-08-09 08:45, Aleksey Shipilev wrote:
On 08/09/2016 12:09 AM, Paul Sandoz wrote:
+1
Looks good to me too.
Thanks!
Pushed.
/Claes
Hi,
The below issues have been closed,
JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285,
JDK-8031555
but the associated items still be contained by ProblemList.txt. This
small patch removes them.
Issue: https://bugs.openjdk.java.net/browse/JDK-8160611
Webrev:
On 09.08.2016 15:58, Claes Redestad wrote:
On 2016-08-09 14:41, Ivan Gerasimov wrote:
Hi Claes!
Not a thorough review, but a minor comment.
209 .replaceAll("DMH.invoke", "DMH/.invoke")
The dot in the regexp needs to be escaped here.
"Needs" is a strong word
On 2016-08-09 13:48, Claes Redestad wrote:
Hi,
change to enable DMH pre-generation caused a subtle change in the
stacktrace, which caused this test to fail.
Please review this patch which reverts the stackframe to look like
before for non-pregenerated DMHs, while also updating the test to
On 2016-08-09 14:41, Ivan Gerasimov wrote:
Hi Claes!
Not a thorough review, but a minor comment.
209 .replaceAll("DMH.invoke", "DMH/.invoke")
The dot in the regexp needs to be escaped here.
"Needs" is a strong word here, but I agree it's more correct. I'll fix
Hi Daniel,
Thanks for your review!
Please take a look at this updated webrev:
http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/
Best regards,
John Jiang
On 2016/8/9 17:53, Daniel Fuchs wrote:
Hi John,
JDK-8061177 [1] has been resolved as a duplicate of
JDK-8065756 [2] which is still
On 2016-08-09 14:31, Ivan Gerasimov wrote:
Hi Claes!
src/java.base/share/classes/sun/invoke/util/ValueConversions.java:
43 /** EnumMap uses preconstructed array internally, which
is constant during it's lifetime. */
44 @Stable
45 private final MethodHandle[]
> On 9 Aug 2016, at 13:26, Claes Redestad wrote:
>
>
>
> On 2016-08-09 13:48, Claes Redestad wrote:
>> Hi,
>>
>> change to enable DMH pre-generation caused a subtle change in the
>> stacktrace, which caused this test to fail.
>>
>> Please review this patch which
Hi,
please review this set of small changes to reduce the number of classes
defined and pulled in when initializing java.lang.invoke
Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8163370
- Using an EnumMap in
Hi Claes!
src/java.base/share/classes/sun/invoke/util/ValueConversions.java:
43 /** EnumMap uses preconstructed array internally, which is
constant during it's lifetime. */
44 @Stable
45 private final MethodHandle[] map = new
MethodHandle[Wrapper.COUNT];
The
Hi Claes!
Not a thorough review, but a minor comment.
209 .replaceAll("DMH.invoke", "DMH/.invoke")
The dot in the regexp needs to be escaped here.
With kind regards,
Ivan
On 09.08.2016 15:26, Claes Redestad wrote:
On 2016-08-09 13:48, Claes Redestad wrote:
Hi,
Kumar, thank you for that information. I find that useful too. Now with
regard to this email's proposal, are there any further opinions? If this
has merit, I would appreciate if someone could create a ticket for
consideration?
Cheers,
Paul
On Mon, Aug 8, 2016 at 4:20 PM, Kumar Srinivasan <
Opinions!
1. --version:9 is ambiguous, maybe --require-version=9 would be better...
2. ... but it still doesn't seem worth the hours of testing, maintenance
and subsequent bug-fixing for this niche use case
3. ... and even if it did get in there'd be a very long time until all
versions of java
> On 9 Aug 2016, at 05:04, Claes Redestad wrote:
>
> Hi,
>
> please review this set of small changes to reduce the number of classes
> defined and pulled in when initializing java.lang.invoke
>
> Webrev: http://cr.openjdk.java.net/~redestad/8163370/webrev/
> Bug:
Hi,
please review this patch to replace reflection calls into
java.lang.invoke from GenerateJLIClassesPlugin with an internal API
exported to jdk.jlink via JavaLangInvokeAccess/SharedSecrets.
Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/
Bug:
On 2016-08-09 16:27, Paul Sandoz wrote:
On 9 Aug 2016, at 05:04, Claes Redestad wrote:
Hi,
please review this set of small changes to reduce the number of classes defined
and pulled in when initializing java.lang.invoke
Webrev:
Am 08/08/16 um 01:16 schrieb Claes Redestad:
> Hi Christian,
>
> have you looked at java.util.concurrent.ForkJoinPool.commonPool()?
Thanks for pointing that out. I looked at Java 7 documentation and did
not notice a common pool got added in Java 8. I will postpone any effort
on parallelization
Am 08/08/16 um 02:04 schrieb Brian Goetz:
> If a library wants to offer a customization point where it accepts an
> FJPool, clients should be encouraged to pass the common pool (and the
> common pool is a good default) unless there are specific reasons not to.
Exposing parallelization at API
> On Aug 8, 2016, at 8:51 AM, Paul Benedict wrote:
>
> However, I would like to propose bringing back the option with a different
> purpose. I would like to use --version: as a validation check. I
> want Java to execute ONLY if the version specified matches the actual
>
> On Aug 9, 2016, at 3:52 AM, Per Liden wrote:
>
> Hi Kim,
>
> On 2016-08-09 03:25, Kim Barrett wrote:
>>> On Aug 8, 2016, at 8:16 AM, Per Liden wrote:
>>> I have one suggestion though, regarding CheckReferencePendingList(). While
>>> reviewing I
43 matches
Mail list logo