- Mail original -
> De: "Claes Redestad"
> À: "Remi Forax"
> Cc: "core-libs-dev@openjdk.java.net Libs"
> Envoyé: Mardi 17 Novembre 2015 23:08:55
> Objet: Re: RFR(XS): 8143127: InvokerBytecodeGenerator emitConst should handle
> Byte, Short, Character
>
> Hi Remi,
>
> On 2015-11-17 22:1
> On Nov 17, 2015, at 1:13 PM, Peter Levart wrote:
>
> But (as described in my other message), Runnable::run is not an entry point.
> Thread::run is. And Thread::run (a Java method) delegates to Runnable::run.
> So in this case Thread.class will be returned as a normal caller (which it
> real
Hi Alan,
Thanks for looking at this.
>> Please review the new webrev that addresses the issues raised by Sherman and
>> Alan in the last iteration. In particular:
>> - fixed the race condition in isMultiRelease() and another one with the
>> variables ‘version’ and ‘configured’
>> - changed the
On Nov 17, 2015, at 4:00 PM, Ian Rogers wrote:
>
> Should the StackWalker.StackFrame interface provide a way to get the
> java.lang.reflect.Method/Constructor/Member?
>
Not in the scope of this JEP.
Mandy
> Thanks,
> Ian
>
> On Tue, Nov 17, 2015 at 3:56 PM, Mandy Chung wrote:
> Thanks Pete
Thanks Peter.
> - threre's no ResourceBundle.getBundle(String, ClassLoader) method.
> - Util -> ResourceBundleUtil (or ResourceBundleUtil -> Util)
>
Fixed.
> :
> - Stream.findFirst() returns Optional, not E.
>
Fixed.
I updated javadoc for getCallerClass per our discussion.
/**
* Gets the
On 11/17/2015 09:50 PM, Mandy Chung wrote:
On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart
wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
Hi Konstantin,
Technically, getInvokedynamicRefInfoAt should be
getNameAndTypeOfInvokedynamicRefInfoAt because it only extract the nameAndType
value of the InvokeDynamicRef.
In term of API, I think it's better to decompose the API, i.e. to have a method
int getInvokedynamicRefNameAndTypeIndex(
Hi Mandy,
On 11/17/2015 01:13 AM, Mandy Chung wrote:
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of
> Apart from the orphaned paragraph fragment at the end looks good to me, but
> that’s just my opinion.
I caught that that after I clicked sent :(
This is a better version.
/**
* Gets the {@code Class} object of the caller invoking the method
* that calls this {@code getCallerClass} method.
Looks good to me.
In an unmodularized world I would think twice before adding the
hotspot specific tags.
(I'm not a HotSpot Reviewer).
cheers
/Joel
On Mon, Nov 16, 2015 at 11:41 PM, Christian Thalinger
wrote:
> [CC'ing core-libs-dev]
>
>> On Nov 13, 2015, at 4:55 AM, Konstantin Shefov
>> wro
On 17/11/15 01:13, Mandy Chung wrote:
I’d like to get the code review done by this week.
I renamed the static factory method from create to getInstance since “create”
implies to create a new instance but the method returns a cached instance
instead. I also changed the spec of getCallerClass p
Hi Remi,
On 2015-11-17 22:13, Remi Forax wrote:
Hi Claes,
I fail to see how this code will not throw a CCE at runtime
if (con instanceof Integer || con instanceof Byte || con instanceof Short ||
con instanceof Character) {
emitIconstInsn((int) con);
...
(int)con is translated by
On 11/17/2015 10:13 PM, Peter Levart wrote:
I will keep returning the thread’s entry point case to return the class of the
runnable instead of returning Thread.class.
But (as described in my other message), Runnable::run is not an entry
point. Thread::run is. And Thread::run (a Java metho
Hi Sherman,
Thanks for looking at this. Comments in-line below.
> On Nov 17, 2015, at 9:49 AM, Xueming Shen wrote:
>
> On 11/11/15 8:44 AM, Steve Drach wrote:
>> Hi,
>>
>> Please review the new webrev that addresses the issues raised by Sherman and
>> Alan in the last iteration. In particul
On 11/11/15 8:44 AM, Steve Drach wrote:
Hi,
Please review the new webrev that addresses the issues raised by
Sherman and Alan in the last iteration. In particular:
- fixed the race condition in isMultiRelease() and another one with
the variables ‘version’ and ‘configured’
- changed the fragme
Hi Claes,
I fail to see how this code will not throw a CCE at runtime
if (con instanceof Integer || con instanceof Byte || con instanceof Short ||
con instanceof Character) {
emitIconstInsn((int) con);
...
(int)con is translated by the compiler to ((Integer)con).intValue()
you have
> On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
>
>
>
> On 11/16/2015 08:16 PM, Mandy Chung wrote:
>>> On Nov 15, 2015, at 10:59 AM, Peter Levart
>>> wrote:
>>>
>>> OTOH in the described cases, a caller of walker.getCallerClass() is
>>> actually expecting to be called by a Java method,
> On Nov 17, 2015, at 10:42 AM, Daniel Fuchs wrote:
>
> On 17/11/15 01:13, Mandy Chung wrote:
>> I’d like to get the code review done by this week.
>>
>> I renamed the static factory method from create to getInstance since
>> “create” implies to create a new instance but the method returns a c
I'd expect this to be superseded by 223 completely but I've cc'd
verona-dev in case there are objections. At this point the fix is more
for the benefit of 7 & 8. I'd be happy to mark this 9-na if that makes
more sense?
-Rob
On 17/11/15 15:19, Alan Bateman wrote:
On 17/11/2015 14:47
On 17/11/2015 14:47, Rob McKenna wrote:
Hi folks,
With 7u hitting 101 shortly we've noticed that our Version parsing
infrastructure balks at the extra digit. With that in mind I'd like to
update the logic surrounding the parsing of version numbers and the
test itself to use regex instead of
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
by a Java method, right? So what would it be if such "caller-sensitive" method demanded
to be call
Hi,
When reflecting over annotated types, there is currently no way to get
the potentially annotated owner of a type. For example, given you have
an instance of '@A Outer . @B Inner' you can't traverse it to get '@A
Outer' .
This API addition fixes this. Because both parameterized and
non-generic
Reviewed.
Best regards,
Vladimir Ivanov
On 11/17/15 5:21 PM, Claes Redestad wrote:
Hi,
it seems I've been testing assertions with the wrong flag.
8142334 added the same assertion check to MethodHandleImpl that was
there for DirectMethodHandle, which
due to some bootstrapping dependency fails
Hi,
it seems I've been testing assertions with the wrong flag.
8142334 added the same assertion check to MethodHandleImpl that was
there for DirectMethodHandle, which
due to some bootstrapping dependency fails for the MethodHandleImpl
case. This patch removes that assertion:
webrev: http://c
On 11/17/2015 02:04 AM, Martin Buchholz wrote:
> On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev
> mailto:aleksey.shipi...@oracle.com>> wrote:
> ForkJoinWorkerThread.newThread/:
> * I think this one requires CCC, because it changes public API in
> newThread.
>
>
> That's where some
Awesome! Looks really good, Michael!
src/java.base/share/classes/java/lang/invoke/MethodHandles.java:
if (!hasPrivateAccess()
|| (specialCaller != lookupClass()
+ // ensure non-abstract methods in
superinterfaces can be special-invoked
+
Looks good.
Best regards,
Vladimir Ivanov
On 11/17/15 2:43 PM, Claes Redestad wrote:
On 2015-11-17 12:22, Vladimir Ivanov wrote:
src/java.base/share/classes/java/lang/invoke/LambdaForm.java:
+ private static void createFormsFor(BasicType type) {
+ synchronized (LF_identity) {
Looks a bit conf
On 2015-11-17 12:22, Vladimir Ivanov wrote:
src/java.base/share/classes/java/lang/invoke/LambdaForm.java:
+ private static void createFormsFor(BasicType type) {
+ synchronized (LF_identity) {
Looks a bit confusing since the method touches both LF_identity and
LF_zero array now. Why not simply m
src/java.base/share/classes/java/lang/invoke/LambdaForm.java:
+ private static void createFormsFor(BasicType type) {
+ synchronized (LF_identity) {
Looks a bit confusing since the method touches both LF_identity and
LF_zero array now. Why not simply make the method synchronized?
LambdaForm is p
On 2015-11-14 01:05, Vladimir Ivanov wrote:
I think we have to add a storeFence or two to avoid publishing
NamedFunctions whose resolvedHandle may otherwise be observed as only
partially visible:
http://cr.openjdk.java.net/~redestad/8142487/webrev.03/
Same here. No need in Unsafe.storeFence
Thank you, Vladimir!
/Claes
On 2015-11-17 11:25, Vladimir Ivanov wrote:
Looks good!
Best regards,
Vladimir Ivanov
PS: I'm impressed by your courage and persistence, Claes :-) Untwining
bootstrapping knot is notoriously hard, especially when you are new to
the code.
On 11/16/15 7:17 PM, Cl
Hi,
this small patch allows InvokerBytecodeGenerator to generate more
compact bytecode for small byte, short and char constants:
webrev: http://cr.openjdk.java.net/~redestad/8143127/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8143127
/Claes
Hi Masayoshi,
Thank you for your feedback and suggestion.
As you said, I understood that There's no perfect solution on the issue because
the short display names(abbreviations) can't be unique.
I was trying to apply the workaround by considering the cases where the short
display names are same
> On 16 Nov 2015, at 22:39, Martin Buchholz wrote:
>
> Smaller than wave 1, but still large. Nothing like a looming deadline to
> spur work ...
>
> Oracle folks will need to help with API review.
>
> https://bugs.openjdk.java.net/issues/?jql=(subcomponent%20%3D%20java.util.concurrent)%20AND%
> On 16 Nov 2015, at 22:39, Martin Buchholz wrote:
>
> Smaller than wave 1, but still large. Nothing like a looming deadline to
> spur work ...
>
> Oracle folks will need to help with API review.
>
> https://bugs.openjdk.java.net/issues/?jql=(subcomponent%20%3D%20java.util.concurrent)%20AND%
Hi folks,
With 7u hitting 101 shortly we've noticed that our Version parsing
infrastructure balks at the extra digit. With that in mind I'd like to
update the logic surrounding the parsing of version numbers and the test
itself to use regex instead of the less flexible CharacterSequence method
Vladimir, Paul,
thanks for looking at this so quickly!
Pushed.
/Claes
On 2015-11-17 15:30, Paul Sandoz wrote:
On 17 Nov 2015, at 15:21, Claes Redestad wrote:
Hi,
it seems I've been testing assertions with the wrong flag.
To share some knowledge: when running jtreg locally it is important
> On 17 Nov 2015, at 15:21, Claes Redestad wrote:
>
> Hi,
>
> it seems I've been testing assertions with the wrong flag.
>
To share some knowledge: when running jtreg locally it is important to use the
same parameters that are used when running the automated tests. To the best of
my knowled
> On 17 Nov 2015, at 13:01, Doug Lea wrote:
> We added more tck tests to check this, and all pass.
> ClassCastException was/is thrown in two cases, without distinguishing them,
> which allowed a path merge by arranging that "cclass" is now the same as
> "vclass" unless field is protected.
>
My
On 2015-11-17 00:06, Martin Buchholz wrote:
On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev <
aleksey.shipi...@oracle.com> wrote:
The primary focus is making jtreg tests more robust and faster.
It also contains the changes to j.u.c.atomic that Aleksey is waiting for.
Yes! Thank you. If you
On 11/17/2015 05:16 AM, Paul Sandoz wrote:
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
—
CCC created.
Thanks, although it is just a clarification that makes
ForkJoinWorkerThreadFactory spec more similar to ThreadFactory.
src/java.base/share/classes/java/util/concurr
Hi Ramanand,
I don't think this fix is correct. This change mixes up time zone IDs
and display names. SimpleDateFomat should parse only display names.
There's no perfect solution on the issue because the short display names
(abbreviations) can't be unique. So, I'd suggest that the UTC display
> On 17 Nov 2015, at 11:25, Vladimir Ivanov
> wrote:
>
> Looks good!
>
> Best regards,
> Vladimir Ivanov
>
> PS: I'm impressed by your courage and persistence, Claes :-) Untwining
> bootstrapping knot is notoriously hard, especially when you are new to the
> code.
>
+1 to that.
Paul.
Looks good!
Best regards,
Vladimir Ivanov
PS: I'm impressed by your courage and persistence, Claes :-) Untwining
bootstrapping knot is notoriously hard, especially when you are new to
the code.
On 11/16/15 7:17 PM, Claes Redestad wrote:
Thanks for the explanation, and patience, Vladimir!
R
44 matches
Mail list logo
