Eclipse OMR Architecture, 26 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OMR Architecture Meeting 20220526

Description

Agenda:
* l2a IL opcode semantics (#6508) [ @jdmpapin ]

A

Welcome everyone to the may 26th omar architecture meeting today we have one topic to discuss um and it's issue 6508, which was initiated by a discussion on a defect that uh popped up on art, 64. and uh devin. Papino has agreed to take us through that discussion. So devin can I turn that over to you.

B

Okay, um oh no, I don't want to do video, that's not it uh can. I can. I share my screen here.

A

As soon as you start.

B

Sharing okay share.

B

And it will be this one, which is.

B

Okay, can everybody see that yeah all right? um So this isn't uh it's not um super fleshed out in terms of opcode stuff, because the op code is very straightforward. um This is more about uh the motivation uh for what I'm suggesting a an op code here.

B

So this is a long or into a gc riff.

B

So at the moment we have along an int to address right. So uh here's our our node and it's got a child of integer, some integer type and it's the integer value of an address and then we convert it to an address type node.

B

um We have two kinds of uh address: uh addresses right, they're, the collected and non-collected ones. So it's basically is this a an object managed by the gce or not.

B

And l2a: well, it's not clear what whether it should be collected right if, if this is the address of a gc object, then of course l2a needs to be collected. But if this is the address of something else, you know a class or something, then it had better not be collected.

B

If we look more closely at the collected case, where did we get this address right and the only way we could have gotten that address really is by taking the actual address type thing and uh and then converting it to an integer? um But when we do this, uh the gc doesn't know about this integer right. It loses track of it, um and so, by the time we use it, uh we could end up with uh the object having been been moved or or having been freed.

B

uh While we were just holding onto this integer there's nothing to keep it fresh.

B

um But we don't um there was this uh pull request a while back uh to stop converting references to integers?

B

um It confuses us about what's collectible and and what's not- and um uh you know we just decided that uh it's there's, there's no uh reliable way to do it really um and we don't even we don't need to make a reliable way either right. uh For example, we had um you know lube strider used to generate this uh tree. That looks kind of like this right.

B

So originally it would have been um an integer comparison on on the uh integer type iv, but then it it creates an address typed one um and then it would still do an integer comparison, but it would convert to.

B

To integers it would convert its address type things to integers, to compare them um and I think.

B

So a possible way that the problem could manifest here is say um this a2l gets uh commoned somewhere further up and there's a gc point in between um yeah. You can have a problem right, so we stopped doing that. It doesn't generate this and uh you know. As of um you know, this pull request and it just generates uh an address comparison.

B

um And uh I think you know anything where we were converting.

B

C

B

C

B

Go ahead: okay um and uh we have this compute is collected reference query that just says: well, if it's a conversion, then it better not be collected right, because um if it's collected.

B

B

But back to this question, of which one is l2a right, here's this this uh collected object case, and this is not allowed really sorry devon. Can you go back to the previous? Your previous.

A

Slide for a sec! uh So that's a question that you ask on the like from your previous slide, the a to the the l to a note or sorry, the a to l note.

B

um It's a question that you can ask uh on uh sorry not on the a2l node, um so this this is the conversion two integer, um as opposed to the conversion from integer right. We are concerned with the conversion uh from integer.

A

B

The thing is that the conversion from integer- if I come back here.

B

um Here's our conversion from integer to address right, and basically it's a it's.

B

It's in the gc managed case.

B

It's only useful um or never mind the gc manage case. It's basically converting the integer to an address generally only makes sense when we have gotten that integer by converting an original address to an integer. First.

B

uh And that conversion from the address to the integer um is what um uh here, you know we uh sort of discovered that it's it's basically not not meaningful.

C

So devin, can you show that tree which used the a2l opcode?

C

I I can see sort of why that was being done and now we may have an ifa compare less than off-road, so we I can see how it doesn't have to use an a2l or maybe over there. So I guess I'm still unclear on. Where do you see l2a uh get used? So is it like? uh If, if we are already using an if a compare less than then there is no a2l in that c? And if there's no a2l, then what are we putting under l2a.

B

So uh one of those is about to come up. I don't have.

A

B

In here, um but the uh the other kind is um uh let's say we have.

B

Let's say we were looking at some code that contains something the compiler knows about, um so uh uh you know take to give a j9 sort of example. um It would be.

B

um You know this method handle has the address of uh of a let's say, a j9 method in it, and it's a long and we have to uh we. We load that out it's long long type, and then um you know maybe some java code loads it and then it passes it to.

B

You know some intrinsic and then the intrinsic says. Oh, I know that this is really an address.

B

B

L2A and that's fine, because this is not the address of a collected- object right- it's not going to move or disappear on us just because our uh reference, like our integer, is unknown to the to the garbage collector.

C

C

Okay, so just go back to that.

A

Slide that you that I asked the question on, can I just see that again yeah this one all right so which, uh which node? Would you ask this question on this.

B

A

B

um So you can ask this: um I don't know that it makes sense to ask it on any node, uh although if it was a not a reference, typed node, I guess you could say false. I didn't um I don't recall what it does in that case, if it, if it asserts or um but it you know it, it really only matters for reference type nodes uh which is to distinguish between.

A

I guess there's.

B

Confusion between these cases, what.

A

Is what goes, what is being returned there if you've got dot dot, dot, t r, no dot dot dot? What's in the dot dot, dot.

B

Oh, that's just um memoization.

A

Okay, so we're going to say.

B

It returns it returns this, but it does it via an intermediate function called. It remembers the result for this node just to avoid a exponential walk. Okay, all.

A

Right, I just wanted to get that clear in my head. Okay,.

B

um uh Anyway, so this uh this question, uh I I suppose it could possibly be posed of the um a2l, but you know it's not really very meaningful for that.

B

um It's the the l to a um we say: no, it's not collected right um and we say that because, uh if it well here, um if it were collected, we would have this case right, and this is the case where we took the address of one of these things and we put it into an integer where the gc can't see it and then now we don't know whether it's good anymore.

B

Right so we say this is not cool and.

B

B

And so then it has to be.

B

This should say non-collected.

B

um This is uh not a collected reference all right, and that seems pretty straightforward, except for compressed reps lowering.

B

So uh we lower the compressed refs they, um you know you do an integer type load of you know some field of some object uh that refers to another.

B

You know, gc managed object, and then we do some arithmetic on it and then convert to address right, and the thing about this is that this is very much a collected reference.

B

um And what happens now is that this puts the uh the cogen into a situation where it's sort of trying to guess whether this thing is collected or not.

B

um And uh you know we, you know the the discussion came about because um the the slack discussion, this sort of um that brought all this up- came about because there was some uh some case or cases where it was guessing wrong.

B

And uh so my suggestion was, let's have a way to you, know just specify, let's just be precise, about whether this is a collected reference or not right and given.

B

You know everything leading up to here. I would want to say this is non-collected um and then we'll add a new one.

B

You know, and this is l or I uh it has exactly the same behavior but the the result is a collected reference.

B

um So that's sort of the uh the the problem statement and my you know brief suggestion for for what to do about it.

C

Okay, so thinking that we may not need a gtf too long off code, because there's no use really for it at the moment, so we just restrict ourselves to what is minimally required here. I assume this l2 gc ref would be used immediately in that compressed rex tree that you showed right.

B

Right that would change to be l2, gc, ref or um i2. Oh well. I guess we don't even necessarily need the I to gcref, because.

B

Compressed references isn't a thing on 32-bit right: you would compress them to there they're already 32-bit.

C

If you're only introducing, basically that one option right, l2 gc right.

A

C

Used in that scenario,.

B

Yes and then everything else um you know anybody else who has an address that they know is good and want to convert it to an address type can use um l2a or i2a, as the case may be, um and uh then you know, cogen will know that that is not collected, and then uh the ones from the compressed roofs lowering would get this and cogen would know that it is collected.

A

So the back end, implementation of that is really just to ensure that a collected reference register is uh allocated for.

B

The converge yes and and to make sure that a non-collected register is used for for these other ones.

A

Are are there any other um means that that we use to determine whether or not a node contains a collected like have we have we done any other attempts over the years to look at these kind of conversion nodes and determine what it's really trying to do? I'm just wondering if any of those cases need to be undone.

A

If we now have a dedicated node. That makes it very explicit.

B

um Not to my knowledge, uh as far as I'm aware, um uh basically these these cases, where we have oh here's, some integer, that's been squirreled away in the in the source, language that we're compiling and but we know that it's an address.

B

um I think those tend to be very short-lived, um not necessarily across a gc point.

B

And I think the if I recall from the discussion, the the cogens seemed to um treat the collectedness of of l2a.

B

In a way that, basically just assumes that it came from the compressed ref's lowering if, whenever compressed rest is on.

B

Right, so, if you're, if your other uses of l2a happen not to cross gc points, um then it is, it doesn't matter what kind of register you've got.

B

So I suspect that they've just been sneaking by.

C

Yeah, I think, there's very few, maybe even literally the ones that devin showed the one that they've ensured where you have a collected presence and this sort of thing is going on. Otherwise it doesn't.

A

C

As he was saying so uh in this case, if you allocate a non-collected register for f for the long value that is below l uh to dc that- and you allocate a collected reference register or collected register for the l2d series, even if the long value has a ref count of one does, that imply some sort of regret, move in the code gen or will it just subsume it like? I.

A

Think it will need a because there there would be distinct registers right. I think virtually I.

C

Think virtual register, but couldn't you do some sort of plumber evaluator.

B

B

It I don't think.

C

Sorry, can you repeat that.

B

Oh wait never mind. I I retract that.

A

It might be, even though the virtual registers have to be distinct, because.

C

There's no question about that. I'm wondering I think.

A

The the the actual register assignment could recognize like if it, if both of those got allocated at the same register, because one died like if the librarians died, it could eliminate that copy.

C

So that could be something to make sure yeah. We could. I think that already happened.

B

I think what I'll say about that point is that I don't think it's um particularly related uh to whether or not we have this new op code.

B

A

Already the case.

B

That uh cogen will see l2a in this compressed riffs case here um and if it ends up with a.

B

uh With a non-collected register and then it it necessarily has to treat this one as collected or you know, nothing is going to work. um It's the same uh issue that must occur today.

C

Yeah yeah, it's more a question of what is the behavior rather than, as you say, it's not an additional point.

C

Arguing for or against l2vc, I I think it's in my opinion, it's a cleaner change. It's a change in the right direction. It makes things cleaner and more explicit um only because you mentioned it in the deck. When I asked there was an earlier slide about his conversion.

C

Is this new october considered a conversion.

B

um So I guess it would be a conversion, um so this um code might need to be adjusted. If this uh I mean, ideally, uh we should probably adjust this code, regardless of whether it's used in in cogen after uh after those l2 gc riff nodes might have been generated.

C

Okay, so so this would be considered a conversion, just as l2a is considered.

B

Right, it's just that.

B

uh It would only be introduced uh very late at a point where we have a handle on on what might happen to uh with uh with the conversions, so that you know we're not creating the kinds of problems where.

B

You know the the kind of confusion that made us stop doing this and the optimizer right um there's not nearly as much transformation going on at that point, and we can have an idea that- um and you know we sort of already do uh have that idea that uh well, these things are going to be.

B

A collective reference uh you know it's the address is the result of this arithmetic and.

B

It's just sort of.

B

Knowing that we will um not hold on to things uh in integer land, um behind the back of the gc for long enough that it becomes a problem, I guess is the the thing that we have to know.

B

Right so the the opcode would just be explicitly distinguishing the those two cases right. It's uh we've generated.

B

You know some round trip through integers that.

B

uh That we are hiding from the gc.

B

uh Versus um in l2a, which you can use at any time, but it had better not refer to gt things.

C

C

This is a again there's: no disagreement in the terms of the principle that here of the chain of the proposal that you have, but just thought I'd ask: did you consider having the l2a as resulting in a collected reference instead and have an l2, not pc? Therefore, some other option, like that- uh I don't know like if address or a represents a collected reference in most cases anyway, and so it's kind of a reason for maybe considering keeping l2a as the one that's collected and the other one is the exception to the roof.

C

I don't have a strong preference myself, it's akin to a a naming discussion really, but I was wondering if I mean I thought I'd just mention it to see. If there's any parts that get triggered.

B

I hadn't really considered that.

A

I think you only found the one case where the l2a is behaving on a like in the compressed reference. That's a connected reference! So there's one case of that, whereas l2a, I think, is used in more places, meaning that there's more of them totally more.

C

A

In the non-collected reference.

C

More common in the code.

A

Yeah, meaning that maybe l2a should apply to non-collected references, and this numerous collective references mark brought up a comment in the in the discussion. The original discussion about whether or not we should have made uh a collective reference, an actual type um which are arguability, would be a much bigger and more pervasive change for sure.

A

um I'm not sure that's needed in this particular. At this juncture, I don't think it's needed, but it's another area to knew about. Maybe.

B

A

So I think I mean at least between this vijay and myself. We seem to be in favor of the uh of this particular proposal.

A

I don't think from an implementation point of view. I mean yes, there will be some work neater on each back end, so that should be relatively minor um and in fact some of that code might even be able to be shared. I mean you're just creating a new collected reference register.

A

Well then, you need to do the moves as well, but anyway it's minor work that needs to happen um and then there's probably a few places in the common code. They need to learn about the new opcode and the semantics of it.

C

But I don't think that that's overwhelming.

A

Does anybody have any uh objections or or see any issues with what has been proposed other than what we've discussed.

A

If not, I think that a a pull request at some point should probably be an order. I don't think you necessarily have to do all the back-end work.

A

You know the introducing the op code could be one pr and then we do the back end. Working.

A

Okay, a bit of a lower priority task too: it's not the original problem. I think we were able to work around in on air 64, but.

A

Okay, any other discussion on this particular topic.

A

Okay, take that as a note, so, okay, thanks for taking us through this uh devon, I think it's a good bit of conceptual integrity that we've uh like, as we just said, is a bit long overdue here so, but we can uh do this going forward.

A

Okay, that's all that we had on the agenda for this week. So thanks everyone for attending and we'll talk again in a couple weeks. Thanks.

C

Bye. Thank you.