Hi Mandy,
This is OK, but the whole loop could be simplified. No need for Dequeue
any more:
// set up proxy class access to proxy interfaces
Set> visited = new HashSet<>(interfaces);
for (Class c : visited) {
ensureAccess(target, c);
On 04/11/2016 01:54 AM, Mandy Chung wrote:
On Apr 10, 2016, at 11:59 AM, Peter Levart wrote:
So here's updated webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/webrev.06/
Looks good to me.
thanks
Mandy
Thanks, pushed.
Regards, Peter
Hi Mandy,
On 04/08/2016 09:45 PM, Mandy Chung wrote:
On Apr 8, 2016, at 3:41 AM, Peter Levart wrote:
Hi,
With Mandy we have prepared the following patch to restore performance of
java.lanf.reflect.Proxy class caching that has regressed with introduction of
additional checks that have to be
On 04/08/2016 12:24 PM, Paul Sandoz wrote:
On 7 Apr 2016, at 19:14, Chris Hegarty wrote:
Enough technical debt has been paid down that we can now create the new
JDK-specific module as proposed by JEP 260 [1], named jdk.unsupported.
This module will initially contain, and export, the sun.misc
Hi,
With Mandy we have prepared the following patch to restore performance
of java.lanf.reflect.Proxy class caching that has regressed with
introduction of additional checks that have to be performed due to modules:
http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.caching/webrev.05/
Jigsaw
Hi Roger,
On 04/05/2016 04:41 PM, Peter Levart wrote:
On 04/04/2016 11:50 PM, Roger Riggs wrote:
I don't see the need to change Cleaner to an interface to be able to
provide
an additional method on CleanerImpl or a subclass and a factory
method could
provide for a clean and very tar
have a couple of ideas to explore.
Thanks, Roger
Regards, Peter
On 4/2/2016 7:24 AM, Peter Levart wrote:
Hi Roger,
Thanks for looking at the patch.
On 04/02/2016 01:31 AM, Roger Riggs wrote:
Hi Peter,
I overlooked the introduction of another nested class (Task) to
handle the c
parts.
I don't have an opinion on the code changes in Reference, that's
different kettle of fish.
More next week.
Have a good weekend, Roger
On 4/1/2016 12:46 PM, Peter Levart wrote:
On 04/01/2016 06:08 PM, Peter Levart wrote:
On 04/01/2016 05:18 PM, Peter Levart wr
On 04/01/2016 06:08 PM, Peter Levart wrote:
On 04/01/2016 05:18 PM, Peter Levart wrote:
@Roger:
...
About entanglement between nio Bits and
ExtendedCleaner.retryWhileHelpingClean(). It is the same level of
entanglement as between the DirectByteBuffer constructor and
Cleaner.register
On 04/01/2016 05:18 PM, Peter Levart wrote:
So I'm going to propose a solution for #1 while still keeping the rest
of webrev unchanged for now and will try to address other issuer
later. Here's new webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webre
On 04/01/2016 05:18 PM, Peter Levart wrote:
@Roger:
...
About entanglement between nio Bits and
ExtendedCleaner.retryWhileHelpingClean(). It is the same level of
entanglement as between the DirectByteBuffer constructor and
Cleaner.register(). In both occasions an action is provided to the
what Panama would provide for
timely deallocation and we could replace the fix in Bits with that when’s
available.
My comments inlined below that are related #1 and #2.
On Mar 28, 2016, at 10:18 AM, Peter Levart wrote:
But first, let me reply to Mandy's comments...
My uncomfort was th
ards, Peter
Roger
On 3/28/2016 1:18 PM, Peter Levart wrote:
Hi Mandy, Kim, Per and Roger
I'd like to continue the discussion about the 2nd part of removing
jdk.internal.ref.Cleaner in this discussion thread.
There was some discussion about whether to synchronize with
ReferenceHandler
On 03/31/2016 08:33 AM, John Rose wrote:
On Mar 30, 2016, at 2:36 AM, Paul Sandoz wrote:
When access is performed in loops this can cost, as the alignment checks are
not hoisted out. Theoretically could for regular 2, 4, 8 strides through the
buffer contents. For such cases alignment of the
string shortening etc
/Claes
On 2016-03-30 17:17, Peter Levart wrote:
Hi Claes,
webrev.04 looks good now.
Maybe just one nit. For production quality, plugin input could be
verified that after expansion it is composed of just the following
characters: "LIJFD". Otherwise ClassWriter migh
MH the validation is not
necessary as the types strings are composed programmatically and are
guaranteed to be correct.
Regards, Peter
On 03/30/2016 04:15 PM, Claes Redestad wrote:
On 2016-03-30 14:21, Peter Levart wrote:
Hi Claes,
On 03/30/2016 12:53 PM, Claes Redestad wrote:
Hi,
I think
ns", which could also handle
https://bugs.openjdk.java.net/browse/JDK-8150044
On 2016-03-30 09:53, Peter Levart wrote:
Hi Claes,
Sorry, I found a flaw in the benchmark (the regex pattern to split
comma-separated string into substrings was wrong). What the benchmark
did was compare t
buf = new StringBuilder().append(signature, 0, i - c0reps);
buf.append((char) c0).append(c0reps);
}
return (buf == null) ? signature : buf.toString();
}
}
Regards, Peter
On 03/30/2016 09:40 AM, Peter Levart wrote:
Hi Claes,
On 03/30/201
Hi Claes,
On 03/30/2016 01:03 AM, Claes Redestad wrote:
Hi Peter, Mandy,
On 2016-03-26 12:47, Peter Levart wrote:
Comparing this with proposed code from webrev:
493 try {
494 return (ClassBoundMethodHandle>)
495 Class.forN
Hi Per,
On 03/29/2016 04:03 PM, Per Liden wrote:
Hi Peter,
On 2016-03-28 19:18, Peter Levart wrote:
[...]
And now a few words about ReferenceHandler thread and synchronization
with it (for Kim and Per mostly). I think it should not be a problem to
move the following two
Hi,
An easy way to make ServiceLoader loaded services decide at runtime for
themselves if they want to be enabled or disabled is a little addition
to their behavior. Suppose that a new exception type is defined:
IgnoreServiceException. When this exception is thrown from the
constructor of the
the ReferenceHandler thread to
the allocating thread(s).
But first, let me reply to Mandy's comments...
On 03/25/2016 11:20 PM, Mandy Chung wrote:
On Mar 19, 2016, at 7:00 AM, Peter Levart wrote:
Here's the webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCl
Hi Claes, Mandy,
On 03/25/2016 03:58 PM, Claes Redestad wrote:
Hi,
On 2016-03-25 11:11, Peter Levart wrote:
Hi Claes, Mandy,
On 03/25/2016 02:51 AM, Mandy Chung wrote:
Hi Claes,
This is a good interesting work to generate
BoundMethodHandle$Species_* classes at link time. This will save
Hi Claes, Mandy,
On 03/25/2016 02:51 AM, Mandy Chung wrote:
Hi Claes,
This is a good interesting work to generate BoundMethodHandle$Species_* classes at
link time. This will save the class generation time. Instead of Class.forName, you
may want to have a class (similar to SystemModules [1])
Hi Kim,
On 03/23/2016 09:40 PM, Kim Barrett wrote:
I don't think there's any throughput penalty for a long timeout. The
proper response to waitForCleanups returning false (assuming the epoch
was obtained early and passed as an argument) is OOME. I really doubt
the latency for reporting OOME is
Hi Aleksey,
Looks nice to me, but I'm not a Reviewer. Quite an improvement for
longer strings.
Regards, Peter
On 03/24/2016 08:31 AM, Aleksey Shipilev wrote:
On 03/16/2016 11:13 AM, Aleksey Shipilev wrote:
I'd like to improve our advanced String concat strategy,
MH_INLINE_SIZED_EXACT, with
On 03/23/2016 09:40 PM, Kim Barrett wrote:
On Mar 23, 2016, at 3:33 PM, Peter Levart wrote:
Hi Kim,
On 03/23/2016 07:55 PM, Kim Barrett wrote:
On Mar 23, 2016, at 10:02 AM, Peter Levart
wrote:
...so I checked what it would be needed if there was such
getPendingReferences() native
proach leads to success...
Regards, Peter
On 03/23/2016 08:33 PM, Peter Levart wrote:
Hi Kim,
On 03/23/2016 07:55 PM, Kim Barrett wrote:
On Mar 23, 2016, at 10:02 AM, Peter Levart wrote:
...so I checked what it would be needed if there was such
getPendingReferences() native method. It turns ou
Hi Kim,
On 03/23/2016 07:55 PM, Kim Barrett wrote:
On Mar 23, 2016, at 10:02 AM, Peter Levart wrote:
...so I checked what it would be needed if there was such
getPendingReferences() native method. It turns out that a single native method
would not be enough to support the precise direct
' will be faster a bit.
Regards, Peter
On 03/23/2016 07:01 PM, Peter Levart wrote:
Hi Xuelei,
On 03/23/2016 04:26 AM, Xuelei Fan wrote:
Hi,
Please review the update for the supporting of BigInteger.TWO:
http://cr.openjdk.java.net/~xuelei/8152237/webrev/
BigInteger.valueOf(2) is a co
Hi Xuelei,
On 03/23/2016 04:26 AM, Xuelei Fan wrote:
Hi,
Please review the update for the supporting of BigInteger.TWO:
http://cr.openjdk.java.net/~xuelei/8152237/webrev/
BigInteger.valueOf(2) is a common BigInteger value used in binary and
cryptography operation calculation. The BigInte
Hi Per, Kim,
On 03/22/2016 10:24 AM, Per Liden wrote:
So, I imagine the ReferenceHandler could do something like this:
while (true) {
// getPendingReferences() is a downcall to the VM which
// blocks until the pending list becomes non-empty and
// returns the whole list, transferrin
On 03/22/2016 10:28 PM, Kim Barrett wrote:
On Mar 22, 2016, at 5:24 AM, Per Liden wrote:
One thing I like about this approach is that it's only the ReferenceHandler
thread that pops of elements from the pending list and enqueues them. That
simplifies things a lot.
I like that too. And hope
Hi Mandy,
Nice to see this fixed. It looks good to me. Thanks!
Regads, Peter
On 03/22/2016 07:41 PM, Mandy Chung wrote:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/
This restores the change in NativeBuffer to use the common Cleaner created by
the system. JDK-8149925 c
On 03/21/2016 04:13 PM, Peter Levart wrote:
Hi Per, David,
As things stand, there is a very good chance that sun.misc.Cleaner
will go away in JDK9, so all this speculation about the source of
OOME(s) can be put to rest. But for JDK 8u, I agree that this should
be sorted out.
My feeling
a and Bits.java for an example of how this
synchronization with ReferenceHandler thread is to be used)
Regards, Peter
On 03/21/2016 04:13 PM, Peter Levart wrote:
Hi Per, David,
As things stand, there is a very good chance that sun.misc.Cleaner
will go away in JDK9, so all this speculation abou
olmes wrote:
Hi Per,
On 21/03/2016 10:20 PM, Per Liden wrote:
Hi Peter & David,
(Resurrecting an old thread here...)
On 2014-01-22 03:19, David Holmes wrote:
Hi Peter,
On 22/01/2014 12:00 AM, Peter Levart wrote:
Hi, David, Kalyan,
Summing up the discussion, I propose the following
.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.08.part2/
So take your time and review at your convenience.
Regards, Peter
On 03/09/2016 10:16 PM, Peter Levart wrote:
Hi Mandy, Chris, Kim, Roger and others,
Hearing no objections for a day, two Reviewers saying it looks ok and
Hi Tagir,
I wonder if lambdas are the right tool in Java to express such
generators. They have something in common - each generator uses a very
specific internal state. So maybe an abstract Splitterator class that
just needs one method to be implemented is perhaps concise enough and
easier to
Hi Mandy, Chris, Kim, Roger and others,
Hearing no objections for a day, two Reviewers saying it looks ok and
successfully re-running the tests, I pushed webrev.07.part1 to jdk9-dev.
Thanks for reviews and comments.
Now to the 2nd part...
On 03/07/2016 07:35 PM, Mandy Chung wrote:
...
And
On 03/09/2016 06:14 PM, Xueming Shen wrote:
On 3/9/16 7:58 AM, Peter Levart wrote:
P.S.
Do you happen to know why String.compareToIgnoreCase /
CASE_INSENSITIVE_ORDER is defined to compare characters transformed
through the following function:
Character.toLowerCase(Character.toUpperCase
On 03/09/2016 05:10 PM, Claes Redestad wrote:
On 2016-03-09 16:58, Peter Levart wrote:
Can this really happen? ASCIICaseInsensitiveComparator was asserting
that
string characters were ASCII, so this situation would have triggered
an assert
with the old code, no?
If assertions were
On 03/09/2016 04:30 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 14:43, Peter Levart wrote:
On 03/09/2016 02:44 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 13:03, Claes Redestad wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why
://cr.openjdk.java.net/~plevart/jdk9-dev/String.CASE_INSENSITIVE_HASHER/webrev.01/
Regards, Peter
On 03/09/2016 03:43 PM, Peter Levart wrote:
On 03/09/2016 02:44 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 13:03, Claes Redestad
wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history
On 03/09/2016 02:44 PM, Chris Hegarty wrote:
On 9 Mar 2016, at 13:03, Claes Redestad wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why java.util.jar.Attributes
was ever using ASCIICaseInsensitiveComparator, it was not clear that
butes attr = attributes;
for (String key : keys) {
bh.consume(attr.getValue(key));
}
}
}
... so nothing drastic.
On 03/09/2016 02:03 PM, Claes Redestad wrote:
On 2016-03-09 13:17, Peter Levart wrote:
When digging through old history to try to find out why
java.util.jar.At
Hi Chris,
On 03/09/2016 12:07 PM, Chris Hegarty wrote:
Hi Peter,
On 9 Mar 2016, at 08:42, Peter Levart wrote:
Hi Chris,
While Attribute.Name.equals() should be comparably fast, what about
Attribute.Name.hashCode() ? Could you for example extend the
AvailableCharsetsCompare benchmark with
Hi Chris,
While Attribute.Name.equals() should be comparably fast, what about
Attribute.Name.hashCode() ? Could you for example extend the
AvailableCharsetsCompare benchmark with a a @Setup method that
constructs (via Attributes.putValue(String, String)) a
java.util.jar.Attributes instance wi
Hi Tagir,
On 03/07/2016 04:30 PM, Tagir F. Valeev wrote:
Hello!
Thank you for your comments!
PL> - in Limiter.put:
Nice catch! A good example when series of minor code refactorings lead
to something strange. Webrev is updated in-place:
http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/w
On 03/07/2016 03:53 PM, Peter Levart wrote:
As there is a good chance that sub-list implementations already
provide fail-fast behavior for structural changes in the backing list.
Ah, well... I checked AbstractMutableList in Eclipse collections and it
doesn't provide fail-fast behavio
On 03/07/2016 01:59 PM, Paul Sandoz wrote:
On 7 Mar 2016, at 12:47, Peter Levart wrote:
What about a Spliterator based on List.subList() method? While the
specification of List.subList() does not guarantee any specific behavior when
underlying list is structurally modified, the
What about a Spliterator based on List.subList() method? While the
specification of List.subList() does not guarantee any specific behavior
when underlying list is structurally modified, the implementations (at
least implementations in JDK based on AbstractList) do have a fail-fast
behavior and
imization for enqueuing from the reference queue seems ok to me
and should be
more efficient than the previous implementation but I think Mandy or
Alan should look at it also.
Thanks, Roger
On 2/25/2016 4:17 AM, Peter Levart wrote:
Hi Alan,
On 02/25/2016 09:00 AM, Alan Bateman wrote:
On 25/
Hi Tagir,
Nice work. I looked at the implementation and have two comments:
- in Limiter.put:
127 final boolean put(T t) {
128 int l = limit;
129 T[] d = data;
130 if (l == 1) {
131 // limit == 1 is the special case: exactly one
le
Hi Amy,
I think that the following test:
178 if (!(Math.abs(now - start) >= 0L && Math.abs(end - now)
>= 0L)) {
...will always be false. Therefore, the test will always succeed.
Perhaps you wanted to test the following:
assert start <= end;
if (start > now || now > end) { ...
Reg
Hi Alan,
On 02/25/2016 09:00 AM, Alan Bateman wrote:
On 25/02/2016 07:24, Peter Levart wrote:
:
I kept the public boolean Cleaner.cleanNextPending() method which now
only deals with enqueued Cleanable(s). I think this method might
still be beneficial for public use in situations where
Hi Kim, Roger, Mandy,
Resending with correct From: field to reach the list too...
On 02/24/2016 12:22 AM, Kim Barrett wrote:
On Feb 23, 2016, at 11:35 AM, Peter Levart wrote:
Hi Roger, Mandy,
Here's another webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/w
Hi Alan,
On 02/23/2016 04:33 PM, Alan Bateman wrote:
On 22/02/2016 21:41, Mandy Chung wrote:
:
I added new method to Cleaner:
public boolean helpClean() { }
I’m in two minds of making this a public method. An explicit way to
enqueue pending references as well as invoke Cleanable::clea
and replaced
the accessor of Cleanable with a simple void free() method (called
free because it deallocates memory).
I think this will have to be submitted to CCC for approval, right?
Can you help me with it?
Regards, Peter
On 02/17/2016 11:34 PM, Kim Barrett wrote:
On Feb 17, 2016, at
On 02/22/2016 11:06 AM, Tagir Valeev wrote:
Hello!
Consider the following code:
Comparator cmp = Comparator.nullsFirst(Comparator.naturalOrder());
System.out.println(Stream.of("a", "b",
null).collect(Collectors.minBy(cmp)));
It prints Optional.empty, so the result is indistinguishable from e
7/2016 11:34 PM, Kim Barrett wrote:
On Feb 17, 2016, at 4:06 AM, Peter Levart wrote:
Hi Kim,
Thanks for looking into this. Answers inline…
Peter,
Thanks for the explanations.
On 02/17/2016 01:20 AM, Kim Barrett wrote:
However, I recall Roger saying there were existing tests that
failed when
On 02/19/2016 03:07 PM, Aleksey Shipilev wrote:
Hi Peter,
On 02/19/2016 05:05 PM, Peter Levart wrote:
Your comment in String:
140 * @implNote Note this field is not {@link Stable}, because we
want
141 * LATIN1 (0) coder to fold too. {@link Stable} would not allow
that,
142
Hi,
Just a stupid question.
Your comment in String:
140 * @implNote Note this field is not {@link Stable}, because we
want
141 * LATIN1 (0) coder to fold too. {@link Stable} would not
allow that,
142 * as it reserves the default value as "not initialized" value.
143 *
On 02/17/2016 10:06 AM, Peter Levart wrote:
On 02/17/2016 01:20 AM, Kim Barrett wrote:
src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java
I don't understand why CleanerImpl needs to be changed to public in
order to provide access to the new drainQueue. Wouldn't it be
Hi Kim,
Thanks for looking into this. Answers inline...
On 02/17/2016 01:20 AM, Kim Barrett wrote:
On Feb 16, 2016, at 11:15 AM, Peter Levart wrote:
Hello everybody,
Thanks for looking into this and for all your comments. Now that it seems we have a
consensus that replacing internal
On 02/17/2016 01:17 AM, Kim Barrett wrote:
On Feb 8, 2016, at 5:46 AM, Peter Levart wrote:
If special-casing in ReferenceHandler is removed then an opportunity opens to
get rid of ReferenceHandler thread altogether. VM/GC could enqueue Reference(s)
to their respective ReferenceQueue(s
Hello everybody,
Thanks for looking into this and for all your comments. Now that it
seems we have a consensus that replacing internal Cleaner with public
Cleaner is not a wrong idea, I created an issue for it [1] so that we
may officially review the implementation. I also created an updated
On 02/14/2016 07:15 PM, Stefan Zobel wrote:
Hi Tagir,
this looks good. I wonder, however, if the signature should
accept a wider range of types, i.e., something like
static Stream iterate(S seed, Predicate
predicate, UnaryOperator f)
I know that the corresponding
static Stream iterate(T
On 02/10/2016 02:16 PM, Chris Vest wrote:
I’m slightly more worried about their array and what it implies, though. This
API requires of me that I’m able to present all of the relevant buffers up
front. In my case, these buffers are shared between multiple threads, so they
are guarded by locks
Hi Chris and others,
On 02/10/2016 02:16 PM, Chris Vest wrote:
It’d be a shame to loose the no-zeroing optimisation, so if that requires a
constructor, then lets find a constructor.
To recap, I have possibly multiple buffers and I only want to use parts of
each. So with the composed buffer I’
On 02/08/2016 10:33 AM, Chris Hegarty wrote:
On 8 Feb 2016, at 06:27, Alan Bateman wrote:
On 07/02/2016 22:20, Peter Levart wrote:
:
If the decision to remove sun.misc.Cleaner was partly influenced by the desire
to maintain just 2 instead of 3 Cleaner(s), then my proposal to migrate JDK
On 02/08/2016 07:27 AM, Alan Bateman wrote:
On 07/02/2016 22:20, Peter Levart wrote:
:
If the decision to remove sun.misc.Cleaner was partly influenced by
the desire to maintain just 2 instead of 3 Cleaner(s), then my
proposal to migrate JDK code to the public API might enable Oracle to
On 02/07/2016 11:20 PM, Peter Levart wrote:
On 02/07/2016 08:01 PM, Jeremy Manson wrote:
Hadoop seems to use sun.misc.Cleaner:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.hadoop/hadoop-common/2.7.1/org/apache/hadoop/crypto/CryptoStreamUtils.java
So you may want to keep it
f and java/nio tests:
http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.02/
Regards, Peter
On 02/07/2016 11:53 AM, Peter Levart wrote:
Hi,
sun.misc.Cleaner has been moved to internal package jdk.internal.ref
recently [1] to clean-up sun.misc namespace. But now that:
the public API might enable Oracle to reconsider
keeping sun.misc.Cleaner.
[1] https://bugs.openjdk.java.net/browse/JDK-8132928
[2] https://bugs.openjdk.java.net/browse/JDK-8148117
Regards, Peter
Jeremy
On Sun, Feb 7, 2016 at 2:53 AM, Peter Levart <mailto:peter.lev...@gmai
Hi,
sun.misc.Cleaner has been moved to internal package jdk.internal.ref
recently [1] to clean-up sun.misc namespace. But now that:
- we have comparable public API (java.lang.ref.Cleaner & Cleanable) [2]
- we have an internal shared java.lang.ref.Cleaner instance
(jdk.internal.ref.CleanerFact
e has been removed and only current time is used to derive
initial seed, so you might not see this deadlock any more with JDK 8u45
and later.
Regards, Peter
On 7/02/2016 4:27 AM, Peter Levart wrote:
On 02/06/2016 01:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortun
On 02/06/2016 01:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortunately java system
classes aren't.
It doesn't seem so. At least, I can't find where main thread locks the
0x040ebee8 monitor:
"Thread-1":
waiting to lock monitor 0x142766ac (object 0x040ebee8, a [
Regards, Peter
On 02/03/2016 12:07 PM, Peter Levart wrote:
Hi Sherman,
I don't currently have any idea how to squeeze the hashtable any more
further. It is already very compact in my opinion. But I noticed a
data race that could result in navigating the half-initialized data
struct
Hi Sherman,
I don't currently have any idea how to squeeze the hashtable any more
further. It is already very compact in my opinion. But I noticed a data
race that could result in navigating the half-initialized data
structure. It is a classical unsafe publication bug. It has been present
bef
On 02/02/2016 05:45 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 11:14 AM, Peter Levart wrote:
Hi Roger,
On 02/02/2016 04:16 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
...
Also if this is to become public API, There's a chance users would
want t
Hi Roger,
On 02/02/2016 04:16 PM, Roger Riggs wrote:
Hi Peter,
On 2/2/2016 6:44 AM, Peter Levart wrote:
...
Also if this is to become public API, There's a chance users would
want to add a handler to the chain of existing handlers or override
them. So what about an API that a
dlerChain == null) {
handle1(nativeHandler); // set native handler
} else {
throw new IllegalStateException(
"Can't set native handler after Java handlers have
already been registered.");
}
}
}
}
Hi Roger,
Is this public API supposed to replace sun.misc.Signal? I don't see why
not. Comparing the APIs, thought they are different in style, I can't
find a feature of sun.misc.Signal that wouldn't be supported by
java.util.Signal except for NativeSignalHandler which in my
understanding is
Hi Kim,
This change will make it practically impossible to miss the enqueued
references. But this could be an opportunity to also clean-up the code a
bit. The checkResult method has an 'obj' parameter whose purpose is not
immediately obvious. It's only used in the following line:
136
On 01/25/2016 05:14 PM, Alan Bateman wrote:
On 25/01/2016 15:27, Peter Levart wrote:
But let me ask something. Doesn't GC processing require (at least in
some phases) that user threads be stopped in a safepoint? What
happens when a user thread is blocked by kernel on memory access?
or and a
registration mechanism (where each registered instance would have it's
changeGuard() method call…
— Gil.
On Jan 24, 2016, at 9:10 AM, Peter Levart wrote:
Hi,
I had an idea recently on how to expedite the collection of an object. It is
simple - just don't let it live long.
On 01/25/2016 02:31 PM, Alan Bateman wrote:
On 24/01/2016 17:10, Peter Levart wrote:
Hi,
I had an idea recently on how to expedite the collection of an
object. It is simple - just don't let it live long.
Here's a concept prototype:
http://cr.openjdk.java.net/~plevart/misc/Close
ular
keep_alive passes have had their chance to mark objects live. This way
only paths that become newly-live via ephemeron processing are subject
to the extra reverse-mapping-lookip cost.
While I haven't been poking at this too long to see if it has holes, I
think it can prod
Hi,
I had an idea recently on how to expedite the collection of an object.
It is simple - just don't let it live long.
Here's a concept prototype:
http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java
The overhead of the check in access methods (getByte()/setByte())
for verifying the functionality.
Regards, Peter
On 01/23/2016 07:25 PM, Gil Tene wrote:
On Jan 23, 2016, at 5:14 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
Hi Gil, it's good to have this discussion. See comments inline...
On 01/23/2016 05:13 AM, Gil Tene wrote:
Hi Gil, it's good to have this discussion. See comments inline...
On 01/23/2016 05:13 AM, Gil Tene wrote:
On Jan 22, 2016, at 2:49 PM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
Ephemeron always touches definitions of at least two consecutive
strengths of reach
o update the OopMap for the
Ephemeron class to exclude the value field - analogue to how this is
done for Reference fields. There's no need for indirection through
another WeakReference to get special treatment for value (exclusion from
traversals).
Regards, Peter
— Gil.
Hi Aleksey,
Good work. Nice to see this integrated.
If StringConcatException ever gets thrown, will it propagate out of the
concatenation expression execution? If yes, then it should probably be
an unchecked exception, right?
Regards, Peter
On 01/22/2016 10:31 AM, Aleksey Shipilev wrote:
d to the number of discovered
Ephemerons. If the reachability of value followed exactly the
reachability of key, then "n" would have to count the number of
discovered Ephemerons + WeakReferences + SoftReferences together. Such
implementation is therefore possible, but has a cost.
Hi Paul,
I found a typo (which was probably caused by unconscious influence from
jigsaw ;-). Search for "Java Memory Module"...
Regards, Peter
On 01/21/2016 11:42 PM, Paul Sandoz wrote:
Hi
This is a request to review the VarHandles API. The code reviews and pushes
will occur separately, an
On 01/21/2016 09:57 AM, David Holmes wrote:
The cc's are going dropped unfortunately - adding by serviceability.
On 21/01/2016 1:19 AM, Peter Levart wrote:
Hi,
On 01/20/2016 03:09 PM, Roger Riggs wrote:
Hi David,
I read an old description; I was expecting the value of the property
Hi,
On 01/20/2016 03:09 PM, Roger Riggs wrote:
Hi David,
I read an old description; I was expecting the value of the property
to be the stack size for the reaper.
That would allow more control and less waste when it needed to be
overridden.
Set it to zero if the default size is desired.
Ro
Hi,
Ephemerons are special kind of references described by Barry Hayes [1].
In the simple variant, they contain two "referents". One is called the
key, which can be viewed as a "weak" referent in the style of Java
reference types (SoftReference, WeakReference, PhantomReference), the
other is
Hi,
Another possibility would be to introduce the following default methods
to Map.Entry:
public interface Map.Entry {
...
default Map.Entry withKey(L key) { ... }
default Map.Entry withValue(W value) { ... }
}
Usage would then look like:
map.entrySet().stream().map(e -> e.withValu
901 - 1000 of 2235 matches
Mail list logo
