Refinement of the Scalarization Process for Value Objects during Parsing and PEA by MichaelHaas99 · Pull Request #3 · MichaelHaas99/graal

MichaelHaas99 · 2026-02-08T12:12:32Z

The main bullet points of this PR are:

make the Scalarization node floating and anchor it when necessary, no location identity is necessary
canonicalize Scalarization nodes
during PEA scalarize new occuring value objects as early as possible
no need anymore to replace nodes in the map with an InlineType node during parsing to propagate it down the IR
remove the InlineTypePlaceholder node
introduce a floating Valhalla object equals node (probably in the next PR)
tracking laravlness per field can be simplified to waiting for a constructor call or FinalFieldBarrier node for inlined constructors, so only a boolean state per object field should be scalarized

We need a way to propagate the Scalarization nodes for method arguments during inlining or inserted during merge processing in PEA through the graph. If that is not easily possible, I think we should move to the implementation of C2 and remove all changes from PEA. My solution would be:

Value objects from outside a compilation unit can be encountered with the following nodes with stamp value object:
Parameter (non OSR) nodes
LoadStatic node
LoadField node
Invoke node

They are non-larval and can be scalarized. Value objects within a compilation unit are normally virtual during PEA but will be materialized in case the constructor is not inlined. So value objects can also be scalarized if they are receiver of an Invoke node with a constructor call. If all constructors are inlined, it is virtual anyway during PEA.
What I mean with scalarization during PEA is that we alias the corresponding node with a virtual alias. The field values are directly loaded below the definition of the node.

A special case are OSR arguments as they may still be larval.
In Graal they are marked with the EntryProxy node and replace by an OSRLocal node after parsing. So how can we scalarize, or in other words know that they are non-larval?
We associate an alias to the Pi node having the OSRLocal node as its input with an object state being materialized and tracking the larval state. Whenever we encounter a node that requires the node to be non-larval and we have not encountered a constructor call or StoreField node in between, so the object state indicates larval, we know that the OSR node must have been non-larval from the beginning onwoards. As the Scalarization node is floating we can set the scalarized values in all object states, as we scalarize directly at the beginning.
When we reach a StoreField node we set the field to initialized in the object state.

Scalarizarion nodes should be made floating and anchored at the earliest possible position. We should rely on location identities as this is not necessary and allows GVN. Value objects are immutable, so it does not make any difference when a field is read, as long as it is non-larval.

As a consequence the input to a Scalarization node inserted during parsing should always be virtual.

MichaelHaas99 · 2026-02-08T12:36:08Z

        obj = closure.getObjectState(this, cacheValue);
        if (obj != null) {
-            assert !obj.isVirtual();
+            assert obj.isMaterialized();


only necessary due to a bug?

MichaelHaas99 · 2026-02-08T12:37:19Z

            tool.createVirtualObject(virtualObject, state, Collections.emptyList(), getNodeSourcePosition(), false, this.oop, this.nonNull, isAllocatedOrNull);
+            for (int i = 0; i < state.length; i++) {
+                ValueNode entry = tool.getEntry(virtualObject, i);
+                ValueNode newEntry =  tool.scalarize(entry);


pass in the type of the value object to the scalarize method as well

MichaelHaas99 · 2026-02-08T12:40:00Z

         * non-larval.
         */
        if (!StampTool.isNullableInlineType(materialized, null) || isLarval()) {
            entries = null;


don't delete entries for value object, as they are strict and final

MichaelHaas99 · 2026-02-08T13:08:15Z

+    protected void scalarize(ValueNode node, PartialEscapeBlockState state, GraphEffectList effects, FixedNode position, GuardingNode guard){
+        tool.reset(state, node, position, effects);
+        VirtualInstanceNode newNode = scalarizeValueObject(node,  state, true, guard);
+        this.addVirtualAlias(newNode, node);


do a sanity check here, for some calls an alias should already exist

…r field load.

MichaelHaas99 · 2026-02-09T20:33:54Z

Put the scalarized field values into all states where this virtual object is also present, and also into the merge state if it is present.

MichaelHaas99 · 2026-02-09T21:06:58Z

+                ValueNode entry = entryState[i];
+                if (StampTool.isNullableInlineType(entry, tool.getValhallaOptionsProvider())) {
+                    VirtualInstanceNode newNode = scalarizeValueObject(entry, state, true, visited, guard, stopAtVirtual);
+                    if(newNode != null) {


create an alias for materialized objects, such that we can scalarize them at any time.

MichaelHaas99 · 2026-02-09T21:16:22Z

As we scalarize a value object as early as possible, if we land in a circle where we can't scalarize any further, we should create an alias for the remaining value object. So a virtual object pointing to a materialized object state. This allows us to scalarize the value object at the next possibility, we will only need to fill in the object state with the field values. The point for doing this, is to have an alias available. We should only do this for nodes that are ReadMultiValue nodes as the result from the current scalarization.

MichaelHaas99 · 2026-02-09T21:17:23Z

A value object without an alias shouldn't be possible anymore. Throw an exception in this case as sanity check.

MichaelHaas99 · 2026-02-09T23:07:39Z

Can we maybe make the scalarization procedure in PEReadEliminationClosure more generic, e.g. we already generalize the behaviour for MultiValue nodes.
To do so we should mark larval nodes with an interface so: NewInstance, OSRLocal.
All non-larval nodes with a value class stamp can be scalarized at the first appearance.

MichaelHaas99 · 2026-02-12T18:55:30Z

+                associateAlias(piNode, state, effects, lastFixedNode.next());
+            }
+        } else if (node instanceof ParameterNode param) {
+            if (StampTool.isNullableInlineType(param, tool.getValhallaOptionsProvider())) {


TODO: we are not allowed to scalarize here if we compile a constructor method

…factoring.

…ems if the value is part of a mapping before.

Alias new allocated objects. Fix error with effects, don't use the index directly but the predecessor function. Don't scalarize ReadMultiValue nodes as they can be scheduled above an invoke and cause a missing object state in the virtual mapping. Add sanity checks to check if an alias is associated to a value object.

…existing one.

Only insert new nodes into scalarizationAliases map. Update isLarval for Pi nodes. Ask for alias on LoadField object.

Remove PEA in entry point. Associate alias to loop phis before first processing.

In case a NewInstance node was not virtualized, make the object state larval.

…irtualize will always be called. Move scalarization into virtualize method.

…ation will handle them then. getAliasAndResolve should return the materialized value for non-value objects.

…ation will handle them then. getAliasAndResolve should return the materialized value for non-value objects. Add a verification after PEA that checks that LoadField node are removed and Scalarization nodes have no guard. Make Invoke, FinalFieldBarrier and Membar node Guarding nodes.

MichaelHaas99 added 7 commits February 7, 2026 21:25

First prototype to scalarize value objects as early as possible.

63b570d

Update prototype for OSR.

771c88a

Make Scalarization node floating.

57aa604

No need for anchors.

13d1db3

Remove replacing in map.

687c092

Add TODO.

01b9783

Scalarize all parameter nodes.

8ceebb6

MichaelHaas99 marked this pull request as draft February 8, 2026 12:12

MichaelHaas99 commented Feb 8, 2026

View reviewed changes

MichaelHaas99 added 3 commits February 8, 2026 17:16

Small bug fixes and refactoring.

147d2e3

Scalarizing Parameter nodes directly should be okay.

ea7b6f6

Scalarize values of multi value node. Adjust scalarization depth afte…

6e33d3a

…r field load.

MichaelHaas99 commented Feb 9, 2026

View reviewed changes

MichaelHaas99 changed the title ~~PEA update for Valhalla~~ Refinement of the Scalarization Process for Value Objects during Parsing and PEA Feb 10, 2026

MichaelHaas99 commented Feb 12, 2026

View reviewed changes

MichaelHaas99 added 2 commits February 14, 2026 14:39

Do not scalarize receiver in constructor method.

f3d34bb

Associate alias to value objects not being scalarized due to loop. Re…

05f0368

…factoring.

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from 589e0e3 to 138b932 Compare February 14, 2026 16:18

Remove unset fields logic and replace it with boolean flag.

ce65670

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from 138b932 to ce65670 Compare February 14, 2026 16:26

MichaelHaas99 added 3 commits February 14, 2026 17:43

Scalarization of load node needs no anchor.

a17e58a

Remove Placeholder node.

736e8e8

Remove manual scalarization in plugin. Add sanity check in PEA.

c60244a

Follow-up fix for virtualize in ReturnResultDecider node.

ee26717

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from e1fc4aa to ee26717 Compare February 18, 2026 14:22

MichaelHaas99 added 5 commits February 18, 2026 15:46

Scalarize before object clone.

0e7c1c7

Refactoring.

b49c4f2

Remove unused variable.

f176551

Fix bugs.

4085454

Fix bugs.

2417f9c

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from db1e5bb to 2417f9c Compare February 20, 2026 15:18

MichaelHaas99 added 10 commits February 20, 2026 18:30

Don't associate aliases after constructor call. This can causes probl…

eadf293

…ems if the value is part of a mapping before.

Move scalarization logic into PEA.

a951db6

Refactor anchor insertion.

e9f6d35

Insert Membar before Object init.

cf82a50

Don't remove barrier in virtualize.

6d4e058

Refactoring.

e7c4951

Don't create a new alias for newly allocated objects, just reuse the …

4d426ae

…existing one.

Use option to check for aliases.

c5b913d

Only insert new nodes into scalarizationAliases map. Update isLarval for Pi nodes. Ask for alias on LoadField object.

Alias of read multi value should not be lost.

2ea3d2c

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from b3ff2c0 to 2ea3d2c Compare February 22, 2026 17:02

MichaelHaas99 added 5 commits February 22, 2026 20:18

Associate alias to all parameter nodes.

d89afcc

Remove PEA in entry point. Associate alias to loop phis before first processing.

Increase getAlias search depth.

4d94abb

Remove updateStatesForScalarized als all nodes have an alias now.

4369137

In case a NewInstance node was not virtualized, make the object state larval.

No need for a guard in second call.

e78b0ef

Create a materialized state directly.

fc80a48

MichaelHaas99 force-pushed the mh/GR-57655-PEA branch from 4e454d9 to fc80a48 Compare February 25, 2026 12:54

MichaelHaas99 added 5 commits February 25, 2026 15:34

Use alias for field entry to trigger creation of alias for phi node.

937e859

As all nodes with a value class stamp are associated with an alias, v…

c9aacfb

…irtualize will always be called. Move scalarization into virtualize method.

Improve visible text of ReadMultiValue node for IGV.

712ed31

Remove complex logic to also alias non-alive nodes, the next PEA iter…

e97f244

…ation will handle them then. getAliasAndResolve should return the materialized value for non-value objects.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refinement of the Scalarization Process for Value Objects during Parsing and PEA#3

Refinement of the Scalarization Process for Value Objects during Parsing and PEA#3
MichaelHaas99 wants to merge 59 commits into
mh/GR-57655from
mh/GR-57655-PEA

MichaelHaas99 commented Feb 8, 2026 •

edited

Loading

Uh oh!

MichaelHaas99 Feb 8, 2026

Uh oh!

MichaelHaas99 Feb 8, 2026

Uh oh!

MichaelHaas99 Feb 8, 2026

Uh oh!

MichaelHaas99 Feb 8, 2026

Uh oh!

MichaelHaas99 Feb 9, 2026

Uh oh!

MichaelHaas99 Feb 9, 2026

Uh oh!

MichaelHaas99 commented Feb 9, 2026 •

edited

Loading

Uh oh!

MichaelHaas99 Feb 9, 2026 •

edited

Loading

Uh oh!

MichaelHaas99 commented Feb 9, 2026 •

edited

Loading

Uh oh!

MichaelHaas99 Feb 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

MichaelHaas99 commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichaelHaas99 Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichaelHaas99 Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MichaelHaas99 commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MichaelHaas99 Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

MichaelHaas99 commented Feb 8, 2026 •

edited

Loading

MichaelHaas99 commented Feb 9, 2026 •

edited

Loading

MichaelHaas99 Feb 9, 2026 •

edited

Loading

MichaelHaas99 commented Feb 9, 2026 •

edited

Loading