Re: [rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Alex Herbert]

On 10/05/2019 15:07, Gilles Sadowski wrote:

Hi.

Le ven. 10 mai 2019 à 15:53, Alex Herbert  a écrit :


On 10/05/2019 14:27, Gilles Sadowski wrote:

Hi Alex.

Le ven. 10 mai 2019 à 13:57, Alex Herbert  a écrit :

Can I get a review of the PR for RNG-101 please.

Thanks for this work!

I didn't go into the details; however, I see many fields and methods like
table1 ... table5
fillTable1 ... fillTable5
getTable1 ... getTable5
Wouldn't it be possible to use a 2D table:
table[5][];
so that e.g. only one "fillTable(int tableIndex, /* other args */)" method
is necessary (where "tableIndex" runs from 0 to 4)?

Yes. The design is based around using 5 tables as per the example code.

The sample() method knows which table it needs so it can directly jump
to the table in question. I'd have to look at the difference in speed
when using a 2D table as you are adding another array access but
reducing the number of possible method calls (although you still need a
method call). Maybe this will be optimised out by the JVM.

If the speed is not a factor then I'll rewrite it. Otherwise it's
probably better done for speed as this is the entire point of the
sampler given it disregards any probability under 2^-31 (i.e. it's not a
perfectly fair sampler).

Note that 5 tables are needed for 5 hex digits (base 2^6). The paper
states using 3 tables of base 2^10 then you get a speed increase
(roughly 1.16x) at the cost of storage (roughly 9x). Changing to 2
tables of base 2^15 does not make it much faster again.

I'll have a rethink to see if I can make the design work for different
base sizes.

That could be an extension made easier with the 2D table, but
I quite agree that given the relatively minor speed improvement
to be expected, it is not the main reason; the rationale was just to
make the code a more compact and a little easier to grasp (IMHO).

Gilles


Benchmark (randomSourceName)
   (samplerType)  Mode  Cnt  Score   Error  Units
DiscreteSamplersPerformance.baseline N/A
 N/A  avgt    5  2.043 ± 0.015  ns/op
DiscreteSamplersPerformance.nextInt SPLIT_MIX_64
 N/A  avgt    5  3.577 ± 0.028  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64   
MarsagliaTsangWangDiscreteSampler  avgt    5  5.550 ± 0.019  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64  
MarsagliaTsangWangDiscreteSampler2  avgt    5  5.974 ± 0.073  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64   
MarsagliaTsangWangSmallMeanPoissonSampler  avgt    5  8.104 ± 0.048  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64  
MarsagliaTsangWangSmallMeanPoissonSampler2  avgt    5  8.217 ± 0.015  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64   
MarsagliaTsangWangBinomialSampler  avgt    5  8.321 ± 0.028  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64  
MarsagliaTsangWangBinomialSampler2  avgt    5  9.277 ± 0.167  ns/op

The Poisson(mean = 22.9) sampler has a small difference:

8.104 - 3.577 = 4.527
8.217 - 3.577 = 4.64

About 2.4% slower.

But the Binomial (n=67,p=0.33) sampler is a fair bit slower:

8.321 - 3.577 = 4.744
9.277 - 3.577 = 5.7

About 20% slower.

So it seems that the JVM cannot optimise the 2D table look-up. It may 
well be due to the use of an interface to support different table 
storage types:


table.get(0, n)

If working direct with the array then:

array[0][n]

may be optimised away to just the second index access.

As it is the following:

table.get0(n)
table.get1(n)
...

is faster than

table.get(0, n)
table.get(1, n)
...

I have to admit that the code with the 2D table is nice and compact. But 
thinking about the implementation it can still support 2, 3, or 5 tables 
with the current approach. The later tables would just be empty.


Here are some results for a quick hack of a 3 table version (the suffix 
10 is for base 10):


Benchmark (randomSourceName)
 (samplerType)  Mode  Cnt  Score   Error  Units
DiscreteSamplersPerformance.baseline N/A
   N/A  avgt    5  2.042 ± 0.008  ns/op
DiscreteSamplersPerformance.nextInt SPLIT_MIX_64
   N/A  avgt    5  3.577 ± 0.025  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64 
MarsagliaTsangWangDiscreteSampler  avgt    5  6.087 ± 2.804  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64    
MarsagliaTsangWangDiscreteSampler2  avgt    5  6.002 ± 0.141  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64   
MarsagliaTsangWangDiscreteSampler10  avgt    5  5.301 ± 0.015  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64  
MarsagliaTsangWangDiscreteSampler102  avgt    5  5.715 ± 0.007  ns/op

There's a timing anomaly for the original 

Re: [rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Alex Herbert]

On 10/05/2019 15:07, Gilles Sadowski wrote:

Hi.

Le ven. 10 mai 2019 à 15:53, Alex Herbert  a écrit :


On 10/05/2019 14:27, Gilles Sadowski wrote:

Hi Alex.

Le ven. 10 mai 2019 à 13:57, Alex Herbert  a écrit :

Can I get a review of the PR for RNG-101 please.

Thanks for this work!

I didn't go into the details; however, I see many fields and methods like
table1 ... table5
fillTable1 ... fillTable5
getTable1 ... getTable5
Wouldn't it be possible to use a 2D table:
table[5][];
so that e.g. only one "fillTable(int tableIndex, /* other args */)" method
is necessary (where "tableIndex" runs from 0 to 4)?

Yes. The design is based around using 5 tables as per the example code.

The sample() method knows which table it needs so it can directly jump
to the table in question. I'd have to look at the difference in speed
when using a 2D table as you are adding another array access but
reducing the number of possible method calls (although you still need a
method call). Maybe this will be optimised out by the JVM.

If the speed is not a factor then I'll rewrite it. Otherwise it's
probably better done for speed as this is the entire point of the
sampler given it disregards any probability under 2^-31 (i.e. it's not a
perfectly fair sampler).

Note that 5 tables are needed for 5 hex digits (base 2^6). The paper
states using 3 tables of base 2^10 then you get a speed increase
(roughly 1.16x) at the cost of storage (roughly 9x). Changing to 2
tables of base 2^15 does not make it much faster again.

I'll have a rethink to see if I can make the design work for different
base sizes.

That could be an extension made easier with the 2D table, but
I quite agree that given the relatively minor speed improvement
to be expected, it is not the main reason; the rationale was just to
make the code a more compact and a little easier to grasp (IMHO).

Gilles


Direct from JMH:

Benchmark (randomSourceName)   
(samplerType)  Mode  Cnt  Score   Error  Units
DiscreteSamplersPerformance.baseline N/A
 N/A  avgt5  2.038 ± 0.015  ns/op
DiscreteSamplersPerformance.nextInt SPLIT_MIX_64
 N/A  avgt5  3.752 ± 1.708  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64   
MarsagliaTsangWangDiscreteSampler  avgt5  5.769 ± 0.005  ns/op
DiscreteSamplersPerformance.sample  SPLIT_MIX_64  
MarsagliaTsangWangDiscreteSampler2  avgt5  5.954 ± 0.038  ns/op

Note: The sampler is very fast!

The baseline is just the timing for JMH to consume an int value. This 
does not even hit the generator. That is the nextInt() method.


So to get the time for the sampler we subtract the nextInt baseline (I 
used the median as one sample was slow):


5.752 - 3.559 = 2.193
5.954 - 3.559 = 2.395

It's about 10% slower using a 2D table.

I've only run this on the Discrete sampler. It is a bit artificial as 
the probability distribution is [0.1, 0.2, 0.3, 0.4] so the tables may 
not be very well filled. I'll repeat for the Poisson sampler as that has 
a long tail and larger tables.


I'm currently favouring leaving the code as it is. It matches the 
original source paper so anyone reading that will understand the code. 
Perhaps it needs more documentation.






The diff for "DiscreteSamplersList.java" refers to
 MarsagliaTsangWangBinomialSampler
but
MarsagliaTsangWangSmallMeanPoissonSampler
seems to be missing.

Oops, I missed adding that back. I built the PR from code where I was
testing lots of implementations.

I've just added it back and it is still passing locally. Travis should
see that too as I pushed the change to the PR.


Regards,
Gilles


This is a new sampler based on the source code from the paper:

George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
Fast Generation of Discrete Random Variables.
Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.

https://www.jstatsoft.org/article/view/v011i03

The code has no explicit licence.

The paper states:

"We have provided C versions of the two methods described here, for
inclusion in the “Browse
files”section of the journal. ... You may then want to examine the
components of the two files, for illumination
or for extracting portions that might be usefully applied to your
discrete distributions."

So I assuming that it can be incorporated with little modification.

The Java implementation has been rewritten to allow the storage to be
optimised for the required size. The generation of the tables has been
adapted appropriately and checks have been added on the input parameters
to ensure the sampler does not generate exceptions once constructed (I
found out the hard way that the original code was not entirely correct).

Thanks.

Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: 

Re: [rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Gilles Sadowski]

Hi.

Le ven. 10 mai 2019 à 15:53, Alex Herbert  a écrit :
>
>
> On 10/05/2019 14:27, Gilles Sadowski wrote:
> > Hi Alex.
> >
> > Le ven. 10 mai 2019 à 13:57, Alex Herbert  a 
> > écrit :
> >> Can I get a review of the PR for RNG-101 please.
> > Thanks for this work!
> >
> > I didn't go into the details; however, I see many fields and methods like
> >table1 ... table5
> >fillTable1 ... fillTable5
> >getTable1 ... getTable5
> > Wouldn't it be possible to use a 2D table:
> >table[5][];
> > so that e.g. only one "fillTable(int tableIndex, /* other args */)" method
> > is necessary (where "tableIndex" runs from 0 to 4)?
>
> Yes. The design is based around using 5 tables as per the example code.
>
> The sample() method knows which table it needs so it can directly jump
> to the table in question. I'd have to look at the difference in speed
> when using a 2D table as you are adding another array access but
> reducing the number of possible method calls (although you still need a
> method call). Maybe this will be optimised out by the JVM.
>
> If the speed is not a factor then I'll rewrite it. Otherwise it's
> probably better done for speed as this is the entire point of the
> sampler given it disregards any probability under 2^-31 (i.e. it's not a
> perfectly fair sampler).
>
> Note that 5 tables are needed for 5 hex digits (base 2^6). The paper
> states using 3 tables of base 2^10 then you get a speed increase
> (roughly 1.16x) at the cost of storage (roughly 9x). Changing to 2
> tables of base 2^15 does not make it much faster again.
>
> I'll have a rethink to see if I can make the design work for different
> base sizes.

That could be an extension made easier with the 2D table, but
I quite agree that given the relatively minor speed improvement
to be expected, it is not the main reason; the rationale was just to
make the code a more compact and a little easier to grasp (IMHO).

Gilles

>
> >
> > The diff for "DiscreteSamplersList.java" refers to
> > MarsagliaTsangWangBinomialSampler
> > but
> >MarsagliaTsangWangSmallMeanPoissonSampler
> > seems to be missing.
>
> Oops, I missed adding that back. I built the PR from code where I was
> testing lots of implementations.
>
> I've just added it back and it is still passing locally. Travis should
> see that too as I pushed the change to the PR.
>
> >
> > Regards,
> > Gilles
> >
> >> This is a new sampler based on the source code from the paper:
> >>
> >> George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
> >> Fast Generation of Discrete Random Variables.
> >> Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.
> >>
> >> https://www.jstatsoft.org/article/view/v011i03
> >>
> >> The code has no explicit licence.
> >>
> >> The paper states:
> >>
> >> "We have provided C versions of the two methods described here, for
> >> inclusion in the “Browse
> >> files”section of the journal. ... You may then want to examine the
> >> components of the two files, for illumination
> >> or for extracting portions that might be usefully applied to your
> >> discrete distributions."
> >>
> >> So I assuming that it can be incorporated with little modification.
> >>
> >> The Java implementation has been rewritten to allow the storage to be
> >> optimised for the required size. The generation of the tables has been
> >> adapted appropriately and checks have been added on the input parameters
> >> to ensure the sampler does not generate exceptions once constructed (I
> >> found out the hard way that the original code was not entirely correct).
> >>
> >> Thanks.
> >>
> >> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Alex Herbert]

On 10/05/2019 14:27, Gilles Sadowski wrote:

Hi Alex.

Le ven. 10 mai 2019 à 13:57, Alex Herbert  a écrit :

Can I get a review of the PR for RNG-101 please.

Thanks for this work!

I didn't go into the details; however, I see many fields and methods like
   table1 ... table5
   fillTable1 ... fillTable5
   getTable1 ... getTable5
Wouldn't it be possible to use a 2D table:
   table[5][];
so that e.g. only one "fillTable(int tableIndex, /* other args */)" method
is necessary (where "tableIndex" runs from 0 to 4)?


Yes. The design is based around using 5 tables as per the example code.

The sample() method knows which table it needs so it can directly jump 
to the table in question. I'd have to look at the difference in speed 
when using a 2D table as you are adding another array access but 
reducing the number of possible method calls (although you still need a 
method call). Maybe this will be optimised out by the JVM.


If the speed is not a factor then I'll rewrite it. Otherwise it's 
probably better done for speed as this is the entire point of the 
sampler given it disregards any probability under 2^-31 (i.e. it's not a 
perfectly fair sampler).


Note that 5 tables are needed for 5 hex digits (base 2^6). The paper 
states using 3 tables of base 2^10 then you get a speed increase 
(roughly 1.16x) at the cost of storage (roughly 9x). Changing to 2 
tables of base 2^15 does not make it much faster again.


I'll have a rethink to see if I can make the design work for different 
base sizes.




The diff for "DiscreteSamplersList.java" refers to
MarsagliaTsangWangBinomialSampler
but
   MarsagliaTsangWangSmallMeanPoissonSampler
seems to be missing.


Oops, I missed adding that back. I built the PR from code where I was 
testing lots of implementations.


I've just added it back and it is still passing locally. Travis should 
see that too as I pushed the change to the PR.




Regards,
Gilles


This is a new sampler based on the source code from the paper:

George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
Fast Generation of Discrete Random Variables.
Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.

https://www.jstatsoft.org/article/view/v011i03

The code has no explicit licence.

The paper states:

"We have provided C versions of the two methods described here, for
inclusion in the “Browse
files”section of the journal. ... You may then want to examine the
components of the two files, for illumination
or for extracting portions that might be usefully applied to your
discrete distributions."

So I assuming that it can be incorporated with little modification.

The Java implementation has been rewritten to allow the storage to be
optimised for the required size. The generation of the tables has been
adapted appropriately and checks have been added on the input parameters
to ensure the sampler does not generate exceptions once constructed (I
found out the hard way that the original code was not entirely correct).

Thanks.

Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Gilles Sadowski]

Hi Alex.

Le ven. 10 mai 2019 à 13:57, Alex Herbert  a écrit :
>
> Can I get a review of the PR for RNG-101 please.

Thanks for this work!

I didn't go into the details; however, I see many fields and methods like
  table1 ... table5
  fillTable1 ... fillTable5
  getTable1 ... getTable5
Wouldn't it be possible to use a 2D table:
  table[5][];
so that e.g. only one "fillTable(int tableIndex, /* other args */)" method
is necessary (where "tableIndex" runs from 0 to 4)?

The diff for "DiscreteSamplersList.java" refers to
   MarsagliaTsangWangBinomialSampler
but
  MarsagliaTsangWangSmallMeanPoissonSampler
seems to be missing.

Regards,
Gilles

> This is a new sampler based on the source code from the paper:
>
> George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
> Fast Generation of Discrete Random Variables.
> Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.
>
> https://www.jstatsoft.org/article/view/v011i03
>
> The code has no explicit licence.
>
> The paper states:
>
> "We have provided C versions of the two methods described here, for
> inclusion in the “Browse
> files”section of the journal. ... You may then want to examine the
> components of the two files, for illumination
> or for extracting portions that might be usefully applied to your
> discrete distributions."
>
> So I assuming that it can be incorporated with little modification.
>
> The Java implementation has been rewritten to allow the storage to be
> optimised for the required size. The generation of the tables has been
> adapted appropriately and checks have been added on the input parameters
> to ensure the sampler does not generate exceptions once constructed (I
> found out the hard way that the original code was not entirely correct).
>
> Thanks.
>
> Alex

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [statistics] Mode function for Cauchy distribution

[Udit Arora]

I am not sure what to say.. I completely agree that most distributions have
undefined statistical values. I dont really have any particular reason for
adding mode in the interface like one mentioned by Sir Alex for mean and
variance. Please let me know if I should go ahead..

On Fri, 10 May 2019, 2:15 am Alex Herbert,  wrote:

>
>
> > On 9 May 2019, at 21:17, Eric Barnhill  wrote:
> >
> > Awesome!
> >
> > On Thu, May 9, 2019 at 10:44 AM Udit Arora 
> wrote:
> >
> >> I will see what I can do. It will take some time, but I will get to know
> >> more about the other distributions.
> >>
> >>
> >> On Thu, 9 May 2019, 10:58 pm Eric Barnhill, 
> >> wrote:
> >>
> >>> Udit, is it clear what to do here? Gilles recommends you propose some
> >> edits
> >>> to ContinuousDistribution instead, to return Mode and Median.
> >>>
> >>> But then, if an interface is altered, all the classes that implement
> that
> >>> interface need to have these functions added, so we hope you are up for
> >> all
> >>> that additional work. We can help you.
>
> I think it would be prudent to go through all the distributions and see
> what is defined for each. Wikipedia has a helper table for all its
> distributions containing:
>
> Mean
> Median
> Mode
> Variance
> Skewness
> Ex. kurtosis
> Entropy
> Fisher Information
>
> If many are undefined then you are adding to an interface something not
> generally supported.
>
> Currently the ContinuousDistribution interface only has the mean and the
> variance. But note that these are used by the inverse cumulative
> probability method in the base abstract class. Same goes for the
> DiscreteDistribution.
>
> I am +0 for adding more methods. I don’t see a reason not to. But nor do I
> see a need (within the library) to have them at the interface level if the
> mode or median for example are not required in a generic way.
>
> >>>
> >>> Last is the idea of accessor methods. if the method starts with get_()
> >> then
> >>> in principle this is just returning a field already present. But with
> >> that
> >>> in mind, I don't know why we already have a method name like getMean()
> in
> >>> this interface. We don't really know whether for a given distribution,
> >> that
> >>> would be a true accessor or need to be calculated. So I think all these
> >>> method names should just be mean(), mode(), median(), etc.
> >>>
> >>> So sorry if this is blowing up into more work than you expected. It
> often
> >>> works that way! I certainly think these changes are worthwhile however.
> >>>
> >>>
> >>>
> >>> On Thu, May 9, 2019 at 7:17 AM Gilles Sadowski 
> >>> wrote:
> >>>
>  Hi Udit.
> 
>  Le jeu. 9 mai 2019 à 12:52, Udit Arora  a
> >> écrit :
> >
> > I intend to add a mode function for the Cauchy Distribution. It is a
>  small
> > addition which i thought might be helpful.
> 
>  How will it be helpful?  I.e. what would an application developer
>  be able to do, that he can't with the current code?
> 
>  You've surely noted that that the class you want to modify is but
>  one of the implementations of the interface "ContinuousDistribution".
>  So if you propose to change the API, the change should be done
>  at the interface level, and the appropriate computation performed, or
>  method overloads defined, for all implementations.
> 
>  The "accessor" methods refer to fields that were set by the
> contructor;
>  e.g. for "CauchyDistribution", "median" and "scale".
>  In this case, it happens that "mode" has the same value as "median",
>  but does this warrant an additional method?
> 
>  Regards,
>  Gilles
> 
> > Thanks
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>  For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[rng] RNG-101 new MarsagliaTsangWang discrete probability sampler

[Alex Herbert]

Can I get a review of the PR for RNG-101 please.

This is a new sampler based on the source code from the paper:

George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
Fast Generation of Discrete Random Variables.
Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.

https://www.jstatsoft.org/article/view/v011i03

The code has no explicit licence.

The paper states:

"We have provided C versions of the two methods described here, for 
inclusion in the “Browse
files”section of the journal. ... You may then want to examine the 
components of the two files, for illumination
or for extracting portions that might be usefully applied to your 
discrete distributions."


So I assuming that it can be incorporated with little modification.

The Java implementation has been rewritten to allow the storage to be 
optimised for the required size. The generation of the tables has been 
adapted appropriately and checks have been added on the input parameters 
to ensure the sampler does not generate exceptions once constructed (I 
found out the hard way that the original code was not entirely correct).


Thanks.

Alex



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

JDK 13 - Early Access build 20 is available

[Rory O'Donnell]

Hi Benedikt,


 *OpenJDK builds *- JDK 13 - Early Access build 20 is available at
 http://jdk.java.net/13/

 * These early-access , open-source builds are provided under the
 o GNU General Public License, version 2, with the Classpath
   Exception .
 * Changes in this build
   

 * Release notes [1]


 *Significant changes since the last availability email*

 * build 20
 o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
   (JDK-8222137)
 o Add new FileSystems.newFileSystem methods (JDK-8218875)
 o Enhance auto vectorization for x86 (JDK-8222074)
 o Remove CollectorPolicy and its subclasses (JDK-8198505)
 o Drop support for pre JDK 1.4 SocketImpl implementations
   (JDK-8216978)
 * build 19
 o add support for generating method handles from a variable symbol
   (JDK-8222744)
 o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
   deprecated (JDK-8222934)
 * build 18
 o Improve String::equals warmup characteristics (JDK-8215017)
 o [Containers] Improve systemd slice memory limit support
   (JDK-8217338)


   Bug fixes for issues reported by Open Source Projects

 * build 20
 o assert(Compile::current()->live_nodes() <
   Compile::current()->max_node_limit()) failed: Live Node limit
   exceeded limit (JDK-8219520)
 o C2: MemNode::can_see_stored_value() ignores casts which carry
   control dependency (JDK-8219902)
 o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
   (JDK-8219991)


 JEP updates since last email

 * JEP 350: Dynamic CDS Archives  
   istargeted for JDK 13.
 * JEP 351: ZGC: Uncommit Unused Memory
    istargeted for JDK 13
 * JEP 353: Reimplement the Legacy Socket API
    moved to Candidate
 * JEP 354: Switch Expressions  moved
   to Candidate.


 OpenJDK Committers’ Workshop, 1–2 August 2019 [2]

Rgds,Rory

[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html

--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland