On 12/10/2012 11:51 AM, Chris Hegarty wrote:
On 07/12/2012 15:46, Remi Forax wrote:
On 12/07/2012 04:34 PM, Chris Hegarty wrote:
I filed 8004707: "Remove superfluous access$000 methods in java.util",
to track this issue. I can file a separate issue for java.lang.
yes, please do that.
I fi
On 07/12/2012 15:46, Remi Forax wrote:
On 12/07/2012 04:34 PM, Chris Hegarty wrote:
I filed 8004707: "Remove superfluous access$000 methods in java.util",
to track this issue. I can file a separate issue for java.lang.
yes, please do that.
I filed 8004797: "Remove superfluous access$000 me
On 12/07/2012 04:34 PM, Chris Hegarty wrote:
I filed 8004707: "Remove superfluous access$000 methods in java.util",
to track this issue. I can file a separate issue for java.lang.
yes, please do that.
I'm sure there are other ways, but a simple find reports them:
:>pwd
build/solaris-i586
I filed 8004707: "Remove superfluous access$000 methods in java.util",
to track this issue. I can file a separate issue for java.lang.
I'm sure there are other ways, but a simple find reports them:
:>pwd
build/solaris-i586/classes/java/util
:> find . -name "*.class" -exec javap -v {} \; |
On 12/06/12 18:44, Remi Forax wrote:
BTW, at some point, it will be a good idea to get ride of all these method
access$000 in java.lang/java.util at least.
Maybe this is out of scope for this CR, but while in the
neighborhood of ThreadLocal, it could be done here.
There are a couple of annoyi
On 12/06/2012 11:05 PM, Jeff Hain wrote:
nitpicking welcome :)
AFAIK (*), removing 'private' for supplier field could prevent
javac to generate accessors for this field, in case it would be
accessed from outside inner class (but since it's not, it would
not yield better perfs, just smaller bytec
>nitpicking welcome :)
AFAIK (*), removing 'private' for supplier field could prevent
javac to generate accessors for this field, in case it would be
accessed from outside inner class (but since it's not, it would
not yield better perfs, just smaller bytecode).
(*) If I correctly undertood what R
On 12/06/2012 09:38 PM, Peter Levart wrote:
On 12/06/2012 08:08 PM, Remi Forax wrote:
On 12/06/2012 08:01 PM, Peter Levart wrote:
There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal extends ThreadLocal {
@Override
public fi
Ok, I've got an explanation.
It's not because of using different static type of variables in code
with final methods, but because TL0 was redirected to a separate method
with separate call sites. The same happens using this variant:
static class TL0 extends ThreadLocal {}
static class
On 12/06/2012 08:08 PM, Remi Forax wrote:
On 12/06/2012 08:01 PM, Peter Levart wrote:
There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal extends ThreadLocal {
@Override
public final T get() { return super.get(); }
On 06/12/2012 19:43, Akhil Arora wrote:
http://cr.openjdk.java.net/~akhil/8003246.3/webrev/
also incorporates a nitpick from Mike -
Objects.requireNonNull returns its arg
Thanks - nitpicking welcome :)
Would it be worth including a note in the withInitial's javadoc to make
it clear that the
On 12/06/2012 11:02 AM, Remi Forax wrote:
just nitpicking,
return new SuppliedThreadLocal(supplier);
should be
return new SuppliedThreadLocal<>(supplier);
Also, can you add a @see in the constructor of ThreadLocal that
references ThreadLocal.withInitialValue(Supplier).
http://cr.openj
On 12/06/2012 01:12 PM, Vitaly Davidovich wrote:
Understood - I'm just trying to make sure I don't have the wrong mental
model of this in my mind. Taking pathology aside (e.g. code cache is full
when time to recompile, poor tiering interaction, etc), I'd expect the fast
inlined path to be restor
On 12/06/2012 08:01 PM, Peter Levart wrote:
There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal extends ThreadLocal {
@Override
public final T get() { return super.get(); }
@Override
public final void set(T v
On 12/06/2012 07:29 PM, Doug Lea wrote:
On 12/06/12 13:00, Akhil Arora wrote:
http://cr.openjdk.java.net/~akhil/8003246.2/webrev/
- added SuppliedThreadLocal inner class
- reverted javadoc changes to no-args constructor
- added null check for Supplier
Great! Thanks for the quick response.
There's a quick trick that guarantees in-lining of get/set/remove:
public static class FastThreadLocal extends ThreadLocal {
@Override
public final T get() { return super.get(); }
@Override
public final void set(T value) { super.set(value); }
@Overrid
On 12/06/12 13:00, Akhil Arora wrote:
http://cr.openjdk.java.net/~akhil/8003246.2/webrev/
- added SuppliedThreadLocal inner class
- reverted javadoc changes to no-args constructor
- added null check for Supplier
Great! Thanks for the quick response.
-Doug
On 12/05/2012 09:10 PM, David Holmes wrote:
Was there a CCC request for this?
Yes, a CCC was submitted on Nov 12, but it was deferred pending a
discussion on this alias. I just updated and resubmitted the CCC based
on Doug and Remi's suggestions.
On 12/06/2012 09:38 AM, Doug Lea wrote:
Much better; thanks!
As a minor matter, it probably makes sense to give that class a
name. Even though it is a non-public static class, the name
will be seen here and there by debuggers, stacktraces, etc,
and the default "$" name will be confusing. As in:
On 12/06/12 12:01, Akhil Arora wrote:
redone - http://cr.openjdk.java.net/~akhil/8003246.1/webrev/
Much better; thanks!
As a minor matter, it probably makes sense to give that class a
name. Even though it is a non-public static class, the name
will be seen here and there by debuggers, stackt
Thank you Akhil, this looks much better.
I'm not completely comfortable with, "The initial value of the variable
is provided by calling the {@code intialValue} method." Similarly, " The
initial value of the variable is determined by invoking the {@code get}
method on the {@code Supplier."
Sh
On 12/06/2012 03:32 AM, Doug Lea wrote:
These seem like really good reasons to implement as you
suggested in last post, with a static factory that uses a non-public
*final* subclass that wires initialValue to supplier call,
and not otherwise modifying the ThreadLocal class.
It has the added bene
Understood - I'm just trying to make sure I don't have the wrong mental
model of this in my mind. Taking pathology aside (e.g. code cache is full
when time to recompile, poor tiering interaction, etc), I'd expect the fast
inlined path to be restored assuming call site type profile (of the ones we
On 12/06/12 06:56, Vitaly Davidovich wrote:
Doug,
When you see the fast to slow ThreadLocal transition due to class loading
invalidating inlined get(), do you not then see it get restored back to fast
mode since the receiver type in your call sites is still the monomorphic
ThreadLocal (and not t
Doug,
When you see the fast to slow ThreadLocal transition due to class loading
invalidating inlined get(), do you not then see it get restored back to
fast mode since the receiver type in your call sites is still the
monomorphic ThreadLocal (and not the unrelated subclasses)? Just trying to
under
On 12/06/12 03:23, Remi Forax wrote:
On 12/06/2012 06:10 AM, David Holmes wrote:
On 6/12/2012 5:39 AM, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work was
done by Jim Gish.
http://cr.
On 12/06/2012 06:10 AM, David Holmes wrote:
On 6/12/2012 5:39 AM, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webr
On 6/12/2012 5:39 AM, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the new Supplier functional interface. Please review. This work
was done by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.
On 12/05/2012 08:51 PM, Doug Lea wrote:
On 12/05/12 14:39, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values
using the
new Supplier functional interface. Please review. This work was done
by Jim Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
h
On 12/05/12 14:39, Akhil Arora wrote:
This patch adds a constructor to ThreadLocal to supply initial values using the
new Supplier functional interface. Please review. This work was done by Jim
Gish.
http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
http://bugs.sun.com/bugdatabase/view_bug.do
Looks good to me.
Mike
On Dec 5 2012, at 11:39 , Akhil Arora wrote:
> This patch adds a constructor to ThreadLocal to supply initial values using
> the new Supplier functional interface. Please review. This work was done by
> Jim Gish.
>
> http://cr.openjdk.java.net/~akhil/8003246.0/webrev/
>
31 matches
Mail list logo
