looks good,
Vicente
On 01/12/2018 07:31 PM, Kumar Srinivasan wrote:
Hello,
Could I get a review for this simple update to the 3rd party legal
(TPL) information.
Thanks
Webrev: http://cr.openjdk.java.net/~ksrini/8195072/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8195072
Curren
Maybe you should also add a comment for this line:
NoCatalogFound = JAXP09030003: No Catalog is specified.
Thanks,
Leo
On 01/13/2018 03:40 AM, huizhe wang wrote:
Hi,
Please review a doc-only change that adds a few notes to message files that serves as a notification to translation
teams tha
Hello,
Could I get a review for this simple update to the 3rd party legal (TPL)
information.
Thanks
Webrev: http://cr.openjdk.java.net/~ksrini/8195072/webrev.00/
JBS: https://bugs.openjdk.java.net/browse/JDK-8195072
Current ASM copyright:
http://hg.openjdk.java.net/jdk/jdk10/file/c674ff28c69
Looks good!
Thanks for problem listing this test!
/Jesper
> On 12 Jan 2018, at 23:29, Igor Ignatyev wrote:
>
> http://cr.openjdk.java.net/~iignatyev//8195067/webrev.00/index.html
>> 2 lines changed: 1 ins; 0 del; 1 mod;
>
> Hi all,
>
> could you please review this tiny fix which put
> tools
http://cr.openjdk.java.net/~iignatyev//8195067/webrev.00/index.html
> 2 lines changed: 1 ins; 0 del; 1 mod;
Hi all,
could you please review this tiny fix which put
tools/javac/jvm/VerboseOutTest.java into the problem list till 8194968 is fixed?
webrev: http://cr.openjdk.java.net/~iignatyev//81
OK.
Sorry for the bad test.
-- Jon
On 01/12/2018 02:29 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8195067/webrev.00/index.html
2 lines changed: 1 ins; 0 del; 1 mod;
Hi all,
could you please review this tiny fix which put
tools/javac/jvm/VerboseOutTest.java into the pro
+1
> On Jan 12, 2018, at 2:40 PM, huizhe wang wrote:
>
> Hi,
>
> Please review a doc-only change that adds a few notes to message files that
> serves as a notification to translation teams that some technical terms shall
> not be translated.
>
> JBS:
> https://bugs.openjdk.java.net/browse/JDK
Hi,
Please review a doc-only change that adds a few notes to message files
that serves as a notification to translation teams that some technical
terms shall not be translated.
JBS:
https://bugs.openjdk.java.net/browse/JDK-8181047
webres:
http://cr.openjdk.java.net/~joehw/jdk10/8181047/webrev
On Jan 12, 2018, at 10:12 AM, Alan Bateman wrote:
> On 11/01/2018 22:14, Brian Burkhalter wrote:
>> Thanks. The final version is updated in place under webrev.03. Pushing the
>> change is pending CSR-reapproval.
>>
>>
> Looks okay to me. Just a minor nit in the first line of nullInputStream w
On 1/12/18, 10:22 AM, Roger Riggs wrote:
Hi Sherman,
flag0 javadoc:
/**
957 * The pattern flags used during compiling. The flags might
be turn*ed* on and
958 * off by*an *embedded flag.
959 */
2946-3047: Can an exception happen between save and restore? Would the
value of
Hi Sherman,
flag0 javadoc:
/**
957 * The pattern flags used during compiling. The flags might be
turn*ed* on and
958 * off by*an *embedded flag.
959 */
2946-3047: Can an exception happen between save and restore? Would the
value of flag0 matter if so?
+Copyright year upda
sure, if you prefer, it's fine for me.
Remi
On January 12, 2018 6:09:27 PM UTC, Paul Sandoz wrote:
>Hi Remi,
>
>Catching up after the holidays. I would prefer to leave both things as
>they are.
>
>Thanks,
>Paul.
>
>> On 22 Dec 2017, at 03:15, fo...@univ-mlv.fr wrote:
>>
>>
>>
>> De: "Paul Sa
On 11/01/2018 22:14, Brian Burkhalter wrote:
Thanks. The final version is updated in place under webrev.03. Pushing the
change is pending CSR-reapproval.
Looks okay to me. Just a minor nit in the first line of nullInputStream
where the javadoc has "contains no bytes". I assume you mean to p
Hi Remi,
Catching up after the holidays. I would prefer to leave both things as they are.
Thanks,
Paul.
> On 22 Dec 2017, at 03:15, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Paul Sandoz"
> À: "Remi Forax"
> Cc: "core-libs-dev"
> Envoyé: Vendredi 22 Décembre 2017 01:38:37
> Objet: Re: [10] RFR
Or you can use method handles ...
I've not tested but this should work:
https://gist.github.com/forax/e49d63d50e5973f602f720ba3b6ea1b8
I have implemented two semantics, either do a call to get field value the first
time (FIRST_WIN) and then for the subsequent calls always return this value as
a
On Fri, Jan 12, 2018 at 11:28 AM Jason Greene
wrote:
>
> > On Jan 12, 2018, at 6:50 AM, Vladimir Ivanov <
> vladimir.x.iva...@oracle.com> wrote:
> >
>
> -snip-
>
> > So, the worst case scenario is: a value written into @Stable
> field/array is never visible in some code no matter what you do. It
Hi,
Please help review the change for JDK-8194667
issue: https://bugs.openjdk.java.net/browse/JDK-8194667
webrev: http://cr.openjdk.java.net/~sherman/8194667/webrev
The bits of "flags" are being updated on and off during the pattern
compiling by
the possible embedded match flag(s) in old imple
> On Jan 12, 2018, at 6:50 AM, Vladimir Ivanov
> wrote:
>
-snip-
> So, the worst case scenario is: a value written into @Stable field/array is
> never visible in some code no matter what you do. It can lead to nasty bugs
> when different parts of program don't agree on observed value. It c
ok, in that case, no additional Warning message is needed, the useful
warning has already been printed.
Thanks, Roger
On 1/12/2018 10:42 AM, Kumar Srinivasan wrote:
Hi Roger,
Thanks for looking at this.
Hi Kumar,
RunPathTest should say *what* is missing from the environment to skip
the te
Hi Roger,
Thanks for looking at this.
Hi Kumar,
RunPathTest should say *what* is missing from the environment to skip
the test.
Otherwise, the curious has to go back a read the code to figure it out.
Actually it *does* say *what* is missing, however it will be printed
before this messag
Looping in core-libs.
The following fix alters the module-info for java.base. Can someone from the
core-libs comment
on these changes?
I’d also like to remove the two PerfDataFile.getFile methods? Since these are
in jdk.internal.jvmstat, can
I just pull them or do they need to go through depr
Hi Kumar,
RunPathTest should say *what* is missing from the environment to skip
the test.
Otherwise, the curious has to go back a read the code to figure it out.
Thanks, Roger
On 1/11/2018 6:00 PM, Kumar Srinivasan wrote:
Hi,
Please review bug fixes for 2 test bugs, which fails with a bas
On Fri, Jan 12, 2018 at 7:50 AM, Vladimir Ivanov <
vladimir.x.iva...@oracle.com> wrote:
> Would you be so kind to explain how this breakage occurs? I can
>>> understand that improper use of @Stable annotation may break the
>>> intended semantics of a program, but to break the integrity of VM? I'm
Would you be so kind to explain how this breakage occurs? I can
understand that improper use of @Stable annotation may break the
intended semantics of a program, but to break the integrity of VM? I'm
trying to imagine the scenario, but can't.
One example might be a @Stable array field used with
On 01/12/2018 01:11 PM, Vitaly Davidovich wrote:
On Fri, Jan 12, 2018 at 6:36 AM Peter Levart wrote:
Hi Andrew,
On 01/12/2018 09:47 AM, Andrew Haley wrote:
On 12/01/18 04:33, Jason Greene wrote:
The internal @Stable facility provides the desired semantics and
precision, but it is heavily
On Fri, Jan 12, 2018 at 6:36 AM Peter Levart wrote:
> Hi Andrew,
>
> On 01/12/2018 09:47 AM, Andrew Haley wrote:
> > On 12/01/18 04:33, Jason Greene wrote:
> >
> >> The internal @Stable facility provides the desired semantics and
> >> precision, but it is heavily locked down, with privileged code
Hi Andrew,
On 01/12/2018 09:47 AM, Andrew Haley wrote:
On 12/01/18 04:33, Jason Greene wrote:
The internal @Stable facility provides the desired semantics and
precision, but it is heavily locked down, with privileged code
checks and export restrictions. Could this be made more accessible
(or p
On 01/12/2018 05:33 AM, Jason Greene wrote:
> MethodHandle.invokeExact() can match the performance of direct invocation,
> but it requires
> constant folding to do so. Otherwise results are similar to Java
> reflection(e.g [1]).
>
> While TrustFinalNonStaticFields can be used, it’s a sledgehamme
Hello,
The javadoc for Inflater states that:
* Note: When using the 'nowrap' option it is also necessary to provide
* an extra "dummy" byte as input. This is required by the ZLIB native
* library in order to support certain optimizations.
This doesn't seem to be a requirement anym
On 12/01/18 09:06, Laurent Bourgès wrote:
> I already made my fields (& constants) final but it is not enough to let
> hotspot trust totally my code, isn't it ?
To some extent yes, to some extent no. HotSpot really does trust
static final constants not to change, so @Stable won't help you
with th
Hi,
I am the author of the Marlin renderer, integrated in both java.desktop &
javafx.graphics modules.
I wonder if such core annotations @Stable @ForceInline ... could be allowed
to such openjdk modules in order to improve performance.
Marlin already uses jdk.internal.Unsafe but @Stable looks pr
Thank you Alan and Sundar for your quick review.
Changes pushed.
Thanks,
Amy
On 12/01/2018 4:51 PM, Alan Bateman wrote:
On 12/01/2018 04:51, Amy Lu wrote:
Please review this minor test-tag-only change to move bugid from
@test to @bug
bug: https://bugs.openjdk.java.net/browse/JDK-8194959
w
On 12/01/2018 04:51, Amy Lu wrote:
Please review this minor test-tag-only change to move bugid from @test
to @bug
bug: https://bugs.openjdk.java.net/browse/JDK-8194959
webrev: http://cr.openjdk.java.net/~amlu/8194959/webrev.00/
Looks good.
On 12/01/18 04:33, Jason Greene wrote:
> The internal @Stable facility provides the desired semantics and
> precision, but it is heavily locked down, with privileged code
> checks and export restrictions. Could this be made more accessible
> (or perhaps a variant restricted to just final fields)?
34 matches
Mail list logo
