Thanks Vitaly. Best to cleanup. I'll make that change.
-neil
On 6/19/2014 5:39 PM, Vitaly Davidovich wrote:
Hi Neil,
1054 envName = malloc(pbuflen);
envName is never freed looks like. Probably not a big deal since this
runs only if launcher is traced, but thought I'd
Hi Neil,
1054 envName = malloc(pbuflen);
envName is never freed looks like. Probably not a big deal since this runs
only if launcher is traced, but thought I'd mention it.
Sent from my phone
On Jun 19, 2014 8:30 PM, "Neil Toda" wrote:
>
> Launcher support for modified Nati
Launcher support for modified Native Memory Tracking mechanism in JVM in
JDK9.
Webrev : http://cr.openjdk.java.net/~ntoda/8042469/webrev-03/
bug : https://bugs.openjdk.java.net/browse/JDK-8042469
CCC : http://ccc.us.oracle.com/8042469
Thanks.
-neil
Hello,
I'd prefer to see the CheckJarSigError.sh as a Java program.
Cheers,
-Joe
On 06/19/2014 02:21 PM, Vincent Ryan wrote:
I shortened the output to display only the JAR filename to avoid leaking
filesystem information.
I’ve updated the webrev in-place.
Thanks.
On 19 Jun 2014, at 17:59,
I shortened the output to display only the JAR filename to avoid leaking
filesystem information.
I’ve updated the webrev in-place.
Thanks.
On 19 Jun 2014, at 17:59, Vincent Ryan wrote:
> Please review the following simple changeset to identify the offending JAR
> file following a signature
Hi Sherman,
Looks ok.
Thanks, Roger
On 6/16/2014 1:00 PM, Xueming Shen wrote:
OK, let's go the non-controversial approach. The webrev has been
updated to simply remove
those redundant/duplicated class files from the builder and use the
updated version of the tzdb
builder.
http://cr.openjdk.
On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman
wrote:
> On 19/06/2014 05:25, Martin Buchholz wrote:
>
>> ThreadLocalRandom's clinit method creates an intermediate broken state of
>> ThreadLocalRandom and then proceeds to run some networking code to get
>> some
>> more machine-specific entropy in i
Hi,
an updated webrev with reworked, public methods is available here:
http://cr.openjdk.java.net/~redestad/8041972/webrev.8/
Reviews are yet again appreciated!
/Claes
On 06/17/2014 05:43 PM, Claes Redestad wrote:
Ok, I'm working on improving code and comments based on feedback. I'll
split th
Please review the following simple changeset to identify the offending JAR file
following a signature verification error.
Previously, only the offending entry in the JAR was identified.
This helps during troubleshooting when several JAR files being processed.
The request was originally submitted
On 06/19/2014 03:00 PM, Maurizio Cimadamore wrote:
On 19/06/14 13:53, Remi Forax wrote:
as you can see, javac generate an invokedynamic call with a Foo
instead of a FooBase which I think is the correct behavior.
You mean the other way around?
oops,
s/the correct/not the correct
Maurizio
On 19/06/14 13:53, Remi Forax wrote:
as you can see, javac generate an invokedynamic call with a Foo
instead of a FooBase which I think is the correct behavior.
You mean the other way around?
Maurizio
I've just take a look to bug 8047341 [1] and I think it's a javac bug
and not a bug in the lambda meta-factory,
moreover, Eclipse generates a code which doesn't throw an exception at
runtime.
In list.stream().forEach(TestString::new), TestString::new reference the
constructor of TestString
whi
On 06/19/2014 04:48 AM, Peter Levart wrote:
Or, even better, why not just using the next value from the "seeder" sequence
for the initial value of "secondary" seed and avoid interaction with TLR's main
seed/probe:
Thanks! Or better, just use mix32:
+if ((r = (int)mix64(seeder.get
Or, even better, why not just using the next value from the "seeder"
sequence for the initial value of "secondary" seed and avoid interaction
with TLR's main seed/probe:
diff -r 5b45a5efe417
src/share/classes/java/util/concurrent/ThreadLocalRandom.java
--- a/src/share/classes/java/util/concur
Hi,
I noticed an inconsistency in calling TLR.localInit() method. Everywhere
it's called conditionaly if thread-local "probe" is zero except in
TLR.nextSecondarySeed() where it's called if "secondary" seed is zero.
This re-initializes the "probe" and "seed" even though they might have
already
On 19/06/2014 05:25, Martin Buchholz wrote:
ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some networking code to get some
more machine-specific entropy in initialSeed(). This will fail if the
networking code ever recursively
On 06/19/2014 08:32 AM, Stanimir Simeonoff wrote:
I wonder why just don't use the /dev/random if available on *nix -
implemented by sun.security.provider.NativePRNG or
sun.security.mscapi.PRNG() on Windows that calls CryptGenRandom.
Both support SecureRandomSpi.engineGenerateSeed(int) that provid
Hi Martin,
What version of TLR are you looking at? As far as I remmember, the
InetAddress-related code to obtain initial seed has been replaced by
NetworkInterface.getHardwareAddress(). Is this still triggering the
initialization of InetAddress or is this the case of using
"java.util.secureRa
18 matches
Mail list logo
