Thanks Lance!
Yes, saw them typos :-) Also removed the extra space in apiNote.
Updated webrev below, with removing the text in the javadoc instead of
moving to the header.
http://cr.openjdk.java.net/~joehw/jdk14/8231083/webrev/index.html
-Joe
On 9/19/19 5:18 PM, Lance Andersen wrote:
Hi Jo
On 2019-09-20 00:34, Joe Darcy wrote:
I have not attempted to benchmark any speed differences with and without
the cleanup, but would welcome such an experiment being done.
I ran a quick, naive test by modifying an existing serialization
micro[1], and results are in the noise on default/tiere
Hi Brian,
Now including ObjectInputStream changes:
http://cr.openjdk.java.net/~darcy/8199424.1/
Serialization regression tests still all pass.
Thanks,
-Joe
On 9/19/2019 5:19 PM, Brian Burkhalter wrote:
Hi Joe,
This looks good. Will there be a similar separate patch for
ObjectInputStr
Hi Joe,
Overall this looks good and also cleans up a couple of typos :-)
One nit in both package-info @apiNote, you will notice an extra space before
the was which could be removed before you push
Best
Lance
> On Sep 19, 2019, at 8:00 PM, Joe Wang wrote:
>
> Please review a follow-up doc clar
Hi Joe,
This looks good. Will there be a similar separate patch for ObjectInputStream?
Brian
> On Sep 19, 2019, at 3:34 PM, Joe Darcy wrote:
>
> As part of my serialization work, I noticed some "to do" notes in
> ObjectOutputStream.java to get rid of two native methods once the integral
> <-
Please review a follow-up doc clarification patch after 8230814 [1]. In
this patch, the statement with a reference to the SAX project is moved
to an apiNote in package/sub-package description to reflect the fact
that it is a historical note in nature. The license related text that
appears in th
Hello,
As part of my serialization work, I noticed some "to do" notes in
ObjectOutputStream.java to get rid of two native methods once the
integral <-> floating-point bitwise conversion methods
(Float.floatToIntBits, etc.) were intrinsified. That intrinsification
occurred many releases back a
- Mail original -
> De: "Goetz Lindenmaier"
> À: "Remi Forax"
> Cc: "hotspot-runtime-dev" ,
> "core-libs-dev"
> Envoyé: Mercredi 18 Septembre 2019 09:37:36
> Objet: RE: RFR (L, final): 8218626: Add detailed message to
> NullPointerException describing what is null.
> Hi Remi,
Hi Goet
or make forks/iterations as required parameters when invoking the
microbenchmark through make.
I'm doing the micro test run just for the review and I want it to finish
in short time. Performance runs will be a different configuration.
Mandy
On 9/19/19 1:40 PM, Claes Redestad wrote:
Hi,
FY
- Mail original -
> De: "joe darcy"
> À: "Roger Riggs" , "core-libs-dev"
>
> Envoyé: Jeudi 19 Septembre 2019 21:39:54
> Objet: Re: JDK 14 RFR of JDK-8231202: Suppress warnings on non-serializable
> non-transient instance fields in
> serializable classes
> Hi Roger,
>
> I think the Obj
Hi,
FYI, you can control the number of forks etc run by make test:
make test TEST="micro:java.lang.StackWalkBench"
MICRO="FORK=1;WARMUP_ITER=2;OPTIONS=-p depth=128"
(documented in doc/testing.md|html)
Still, I agree it might be a good idea to have make test TEST=... run
fewer forks/iteration
Hi Roger,
I think the Object -> Serializable type changes you suggest are fine
improvements.
Would you like to push them first ahead of applying @SuppressWarnings to
the remaining locations?
Thanks,
-Joe
On 9/19/2019 12:13 PM, Roger Riggs wrote:
Hi Joe,
The addition of @SuppressWarnings
Hi Joe,
The addition of @SuppressWarnings(serial) hides a number of instances of
poor choices of types. Before they dissappear behind the suppress warnings,
the fix should be to correct the types used.
For example, in the serialization proxies for java.time, the Ser class
carelessly
has a fie
Hi, Daniel
On 9/16/19 3:40 AM, Daniel Fuchs wrote:
However I have some doubts about the the logging benchmark.
Is the benchmark run in a single thread? If not then
there doesn't seem any guarantee that each call to publish()
will be immediately followed by a call to reset(), but instead,
if yo
OK, that makes sense. Andy has already implemented this change (pushed
it to the sandbox), so it will be in the next EA build.
-- Kevin
On 9/19/2019 10:25 AM, mark.reinh...@oracle.com wrote:
jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing
Hi, Mandy
Yes, that 'make' job would take ~7 hours on my machine.
I believe this is typical for running micros using 'make'. AFAICT, the
jmh defaults are used, so it forks (running all the warmups +
iterations) 5 times. Trying another (>100 loc) benchmark at random,
the java.lang.ArrayCopy
jlink’s -o/--output option names exactly the thing being output,
rather than a container for the thing being output.
The jpackage option we’re discussing here names a container for the
thing being output, much like the -d option of javac and javadoc.
Using -d/--dest for jpackage is consistent wit
I also think the list of dependencies is too much.
It is probably being derived in an automatic manner that really isn't
adequate.
For example these (at least) are standard libraries included in the JDK
run time you are verifying
libawt.so()(64bit)
libawt_xawt.so()(64bit)
libjava.so()(64bit)
It seems jpackage should not need to add these Requires to the RPM package.
If adding the JavaFX modules to the runtime image, these so-files are
bundled within the lib directory.
Thus no need for them to be required for installing the RPM.
They should perhaps only be necessary as required if the J
As to why it has this Requires, perhaps I need to address it at the JavaFX
mailinglist.
Yes, that would be best, as this is no longer related to jpackage.
-- Kevin
On 9/19/2019 12:43 AM, Sverre Moe wrote:
Yes it would seem so.
I am still perplexed to why it has an RPM Requires libavcodec
Milan,
This looks like a good start. Please consider
1. Setting TOLERANCE to 5 seconds
2. Getting the second time mark immediately after the query returns (i.e. do
not waste your time in DNSTestUtils.debug(attrs))
3. Making the test parametric instead of hardcoded for the
DEFAULT_DNS_CLIENT_TIM
Thanks for the review, Claes.
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 18. September 2019 19:16
> To: Langer, Christoph ; jdk-updates-
> d...@openjdk.java.net
> Cc: core-libs-dev
> Subject: Re: [11u] RFR 8229773: Resolve permissions for code source URLs
> lazily
>
>
On Wed, 2019-09-18 at 11:07 -0700, Bob Vandette wrote:
> Do you handle the case where there are v1 and v2 subsystems enabled at the
> same time?
Do you mean hybrid hierarchy? I believe so, yes.
Right now, if cpu/cpuset/memory/cpuacct controllers are not bound to a
cgroupv1 hierarchy - 0 of the h
Hi Matthias,
Thanks for cleaning this up.
On 19/09/2019 4:57 pm, Baesken, Matthias wrote:
Hello, as discussed below , I want to cleanup some older references to
sun.java.launcher.pid.
Please review the following change.
After removal of some code belonging old LinuxThreads (JDK-807851
Yes it would seem so.
I am still perplexed to why it has an RPM Requires libavcodec-ffmpeg.so.56.
That one does not exist as far as I can find anywhere. It is not provided
with the ffmpeg package.
I thought perhaps it was the same library as libavcodec.so.56 only named
differently, but considering
On 19/09/2019 07:57, Baesken, Matthias wrote:
Hello, as discussed below , I want to cleanup some older references to
sun.java.launcher.pid.
Please review the following change.
After removal of some code belonging old LinuxThreads (JDK-8078513) ,
the sun.java.launcher.pid handling
26 matches
Mail list logo
