On 10/10/2017 6:17 AM, mandy chung wrote:
David, Peter, Alan
The VM has a fast path to search the symbol from libjava.so first for
bootstrap loader. That was the case I mostly concern about performance
and it's not impacted by this change. Also I consulted with Claes on
the performance imp
David, Peter, Alan
The VM has a fast path to search the symbol from libjava.so first for
bootstrap loader. That was the case I mostly concern about performance
and it's not impacted by this change. Also I consulted with Claes on
the performance impact. I took your suggestion and made
sys
On 2017-10-09 18:22, Xueming Shen wrote:
can some arithmetic calculations + if-else make the cost smaller? not
sure
though.
jshell> ((month - 1) | (12- month) | (day - 1) | (31-day) | (24 - hr)
| (59 - min) | (59 - sec)) < 0
$10 ==> false
Possibly, but given it took almost two years for i
Another possibility is to design the libraries so that they can be built
with a wildcard build, as in @build mypackage.*
I don't see that we will (or want to) ever get to a point in jtreg where
each library class can identify its own dependencies, such as suggested
below.
If the libraries ca
Sorry I used an internal URL. Here's the proper openjdk URL:
http://cr.openjdk.java.net/~iklam/jdk10/8188828_compiler_test_class_not_found.v01/
Thanks
- Ioi
On 10/6/17 1:19 PM, Ioi Lam wrote:
Please review this very simple change:
https://bugs.openjdk.java.net/browse/JDK-8188828
http://ioil
There are several possibilities. One is to pre-compile a bunch of
libraries during the build time, and put them in the classpath using the
jtreg -cpa: option.
Another possibility is to change jtreg to better express the dependency
between different classes compiled by jtreg.
Thanks
- Ioi
On 10/9/17 3:47 AM, Peter Levart wrote:
On 10/09/2017 10:20 AM, Alan Bateman wrote:
On 06/10/2017 20:37, mandy chung wrote:
:
The native libraries map is now created lazily with
synchronization. I keep the lazy initialization that will save to
create a CHM as many custom class loaders
+1,
for 8u/9u we will have to deal with it without any new apis from java.time.
i would assume exception-catch is now fast enough that will not add any
extra measurable burden here.
can some arithmetic calculations + if-else make the cost smaller? not sure
though.
jshell> ((month - 1) | (12- m
On 2017-10-09 16:24, Stephen Colebourne wrote:
On 9 October 2017 at 14:40, Claes Redestad wrote:
In addition to being a cleanup, the move to use java.time did provide a
speedup, however, which
might become significant when loading lots of jar files.
I've not found my notes on how big this sp
On 9 October 2017 at 14:40, Claes Redestad wrote:
> In addition to being a cleanup, the move to use java.time did provide a
> speedup, however, which
> might become significant when loading lots of jar files.
>
> I've not found my notes on how big this speed-up was (I recall ~3x in
> micros), but
On 2017-10-09 11:52, Langer, Christoph wrote:
Hi Matthias,
I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened
before: https://bugs.openjdk.java.net/browse/JDK-8188869.
Please post a webrev for the change as suggested by Claes.
Sounds good to me.
In addition to be
Hi Jack,
UnMarshaller also has the same issue. I would update the webrev given the
number of places to help sanity check for omissions
Best
Lance
> On Oct 8, 2017, at 9:22 PM, Jack Li wrote:
>
> Hi Lance,
>
> the change is incorrect, it should be “javax/xml/bind”.
> thanks a lot for your fin
On 06/10/2017 11:34, Kazunori Ogata wrote:
Hi all,
Please review a change for JDK-8188858.
Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858
Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/
This change caches the result of latestUserDefinedLoader() when objects
are deser
On 10/09/2017 10:20 AM, Alan Bateman wrote:
On 06/10/2017 20:37, mandy chung wrote:
:
The native libraries map is now created lazily with
synchronization. I keep the lazy initialization that will save to
create a CHM as many custom class loaders don't have native code. I
think it's a g
Hi Matthias,
I have closed your bug JDK-8188901 in favor of the bug that Sherman had opened
before: https://bugs.openjdk.java.net/browse/JDK-8188869.
Please post a webrev for the change as suggested by Claes.
Thanks & Best regards
Christoph
> -Original Message-
> From: core-libs-dev [m
Hi Daniel
Thank you very much! I pushed it.
Frank
-Original Message-
From: Daniel Fuchs [mailto:daniel.fu...@oracle.com]
Subject: Re: [10] [testbug] RFR of JDK-8187700 SetAuthenticator tests should
handle the proxy port
Hi Frank,
This looks good to me.
best regards,
-- daniel
On 2
Hi Frank,
This looks good to me.
best regards,
-- daniel
On 28/09/2017 09:37, Frank Yuan wrote:
Hi Daniel and all
Would you like to review
http://cr.openjdk.java.net/~fyuan/8187700/webrev.00/?
Bug: https://bugs.openjdk.java.net/browse/JDK-8187700
I applied the fix for proxy port reusing
On 06/10/2017 20:37, mandy chung wrote:
:
The native libraries map is now created lazily with
synchronization. I keep the lazy initialization that will save to
create a CHM as many custom class loaders don't have native code. I
think it's a good saving. In addition, if we iniitialize th
On 05/10/2017 00:05, Vladimir Kozlov wrote:
https://bugs.openjdk.java.net/browse/JDK-8188775
Changes for 8182701[1] missed changes in default.policy for new module
jdk.internal.vm.compiler.management.
Add missing code:
src/java.base/share/lib/security/default.policy
@@ -154,6 +154,10 @@
Hi Claes, thanks for your feedback.
Hello,
I opened a bug : JDK-8188901 jdk9/10 reject zip/jar files where seconds
value of timestamp is out of supported range 0 - 59
https://bugs.openjdk.java.net/browse/JDK-8188901
In case the dosToJavaTime change was to use java.time was really j
20 matches
Mail list logo
